Cabal and fps merge into base-package
Hello How is one supposed to handle fps being merged to the base package in a Cabal file? Clearly GHC 6.4 will need to depend on the fps package while with GHC 6.5 such a dependency is superfluous, and actually having fps installed will cause conflicts. What is the right solution? - Einar Karttunen
ekarttun:
Hello
How is one supposed to handle fps being merged to the base package in a Cabal file? Clearly GHC 6.4 will need to depend on the fps package while with GHC 6.5 such a dependency is superfluous, and actually having fps installed will cause conflicts.
What is the right solution?
One solution is to provide 2 .cabal files. One default one, using whatever the default compiler needs (i.e. -package fps). And for those on the bleeding edge, a foo.cabal.6.5 perhaps, without the fps package dep. These users would then have to perform one extra step to build the package. I can't think of a native Cabal way to solve this though. We don't allow __GLASGOW_HASKELL__ or such numbers inside .cabal files, or conditionals. -- Don
Hello Donald, Thursday, May 4, 2006, 3:51:53 AM, you wrote:
How is one supposed to handle fps being merged to the base package in a Cabal file? Clearly GHC 6.4 will need to depend on the fps package while with GHC 6.5 such a dependency is superfluous, and actually having fps installed will cause conflicts.
I can't think of a native Cabal way to solve this though. We don't allow __GLASGOW_HASKELL__ or such numbers inside .cabal files, or conditionals.
it will be great to provide such support inside Cabal, otherwise we will need separate installation for each compiler version -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Hello Donald,
Thursday, May 4, 2006, 3:51:53 AM, you wrote:
How is one supposed to handle fps being merged to the base package in a Cabal file? Clearly GHC 6.4 will need to depend on the fps package while with GHC 6.5 such a dependency is superfluous, and actually having fps installed will cause conflicts.
I can't think of a native Cabal way to solve this though. We don't allow __GLASGOW_HASKELL__ or such numbers inside .cabal files, or conditionals.
it will be great to provide such support inside Cabal, otherwise we will need separate installation for each compiler version
One extension I've been working on might be able to handle this. http://hackage.haskell.org/trac/hackage/ticket/27 you may recall there was a fairly long discussion on this a while back :-) Cheers, Simon
participants (4)
-
Bulat Ziganshin -
dons＠cse.unsw.edu.au -
Einar Karttunen -
Simon Marlow