[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