[GHC] #14558: Unable to parse integer-gmp's Cabal file
GHC
ghc-devs at haskell.org
Sat Dec 9 09:42:29 UTC 2017
#14558: Unable to parse integer-gmp's Cabal file
-------------------------------------+-------------------------------------
Reporter: taylorfausak | Owner: hvr
Type: task | Status: new
Priority: normal | Milestone:
Component: Core Libraries | Version: 8.2.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Phyx-):
I wouldn't even care if it was `text` or `directory`. I have a pretty
clear stance on this to prevent hampering our ability to make progress in
the future. If you have a technical merit for the reasons you don't like
`^>=` than that is something we would listen to. However because you don't
see the use of it doesn't mean it's wrong to use it.
Using `^>=` has a clear benefit, and maintainers are free to use any
features that's in the cabal file.
Secondly like `refold` said, `integer-gmp` is a special build-in in that
it requires build system support for systems using in-tree gmp. So there
is a number of configurations that would break if you were to try to
install the `integer-gmp` package.
If you follow the dependency chain you'll notice it depends on `GHC-prim`
which is compiler specific, which further depends on the `rts` package,
which will soon also be a cabal package. Their presence on Hackage as far
as I am aware are only for resolvers. You can't actually install them
short of getting a new GHC version.
Because of this, it is perfectly reasonable to use new bleeding edge
features in these packages. As they are literally tied to GHC, and you
should not be swapping them out/mixing and matching them. We don't
guarantee ABI stability for them at all.
I think we should learn from this experience. There was a non backwards
compatible change in the cabal format. It may have been the first, but it
won't be the last. Let's constructively find a way to prevent things from
breaking in the future. Arguing about whether a library is allowed to use
the bleeding edge isn't useful, the tools should handle this gracefully.
and unless I'm mistaken, don't both `stack` and `cabal-install` do this
now?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14558#comment:26>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list