hi, should we use #if __GLASGOW_HASKELL__ < 710 or #if !MIN_VERSION_base(4,8,0) ? currently both are used in different places, and i have no idea if there is a difference/if it matters. if it does not, i suggest conventionizing one of the two. lennart
On 2015-10-24 at 12:19:38 +0200, lennart spitzner wrote:
hi,
should we use #if __GLASGOW_HASKELL__ < 710 or #if !MIN_VERSION_base(4,8,0) ?
currently both are used in different places, and i have no idea if there is a difference/if it matters. if it does not, i suggest conventionizing one of the two.
IMO, guarding with MIN_VERSION_base() ought to refer to properties of the `base` library (e.g. availability of class instances or other symbols), while guarding with __GLASGOW_HASKELL__ should refer to properties (e.g. availability/semantics of language pragmas) and use of a specific GHC version. While we currently have a 1:1 relationship between base and GHC, this wasn't always the case (and it may make sense to relax this constraint again at some point in the future). Cheers, hvr
On Sat, Oct 24, 2015 at 5:19 AM, lennart spitzner
hi,
should we use #if __GLASGOW_HASKELL__ < 710 or #if !MIN_VERSION_base(4,8,0) ?
currently both are used in different places, and i have no idea if there is a difference/if it matters. if it does not, i suggest conventionizing one of the two.
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. -- Thomas Tuegel
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.... 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
On Sat, Oct 24, 2015 at 10:00 AM, Herbert Valerio Riedel
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....
There is also the case of bootstrapping outside of GHC. For the sake of distro packagers, one should be able to run: $ runhaskell Setup.hs configure $ runhaskell Setup.hs build $ runhaskell Setup.hs install from an unpacked Cabal tarball, outside the GHC tree, and without any special options. It's worth discussing if we want to continue to support that mode of installation.
Moreover, Edward has a patch for GHC to have native MIN_VERSION_... support in GHC:
That's good to know! I look forward to its inclusion. -- Thomas Tuegel
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...is...
participants (3)
-
Herbert Valerio Riedel -
lennart spitzner -
Thomas Tuegel