Re: pre-710 compatibility stuff
On 2015-10-24 at 15:05:44 +0200, Thomas Tuegel wrote: [...] > MIN_VERSION_base is defined by Cabal, so it is not available during > bootstrapping. yes, and that's why we have a cabal_macros_boot.h in GHC's build-system for bootstrapping purposes, http://git.haskell.org/ghc.git/blob/HEAD:/utils/ghc-cabal/cabal_macros_boot.h Moreover, Edward has a patch for GHC to have native MIN_VERSION_... support in GHC: https://ghc.haskell.org/trac/ghc/ticket/10970 https://phabricator.haskell.org/D1349 > This means we unfortunately need to use __GLASGOW_HASKELL__ in Cabal, > even though it isn't really the right macro. It should be safe to use > MIN_VERSION_base in cabal-install. Cheers, hvr ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: pre-710 compatibility stuff
On 24/10/15 15:05, Thomas Tuegel wrote: > MIN_VERSION_base is defined by Cabal, so it is not available during > bootstrapping. This means we unfortunately need to use > __GLASGOW_HASKELL__ in Cabal, even though it isn't really the right > macro. It should be safe to use MIN_VERSION_base in cabal-install. ok, that makes sense, thanks Thomas and Herbert. Herbert also mentioned the qualified import trick to avoid CPP (the "more robust way" on [1]). While it is nifty, i am reluctant to apply it, given the silent/implicit requirement to have at least one reference to the qualified entity. Every contributor to such a module must be aware of this trick or risk accidentally breaking it. The explicitness of CPP seems preferable to me. [1] https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimportof...isredundant ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
