Re: Gearing up for a 1.18 release

Lets change the implementation of `impl` itself then to have ghc == ghcjs = True. This way the special casing is at least localized and not all users of the CompilerId data type need to care. Are there any other such checks that need to be adjusted? On Mon, Aug 26, 2013 at 7:39 AM, Dag Odenhall wrote:

I definitely think impl(ghc) should cover GHCJS, as it effectively just is a GHC backend (even if not part of GHC). Doing otherwise would be a bit like having impl(ghc) be false when compiling with -fllvm IMHO. The value of GHCJS is that it's supposed to be able to compile most existing packages as-is.

Just my two cents. :-)

On Sun, Aug 25, 2013 at 6:53 PM, Luite Stegeman wrote:

...

...

I think we should definitely fix the packages, not put a hack in Cabal.

In the latest hackage archive, there are 462 packages that use the impl(ghc) flag, including lots of very common packages. For example binary:

if impl(ghc >= 7.2.1) cpp-options: -DGENERICS other-modules: Data.Binary.Generic if impl(ghc <= 7.6) -- prior to ghc-7.4 generics lived in ghc-prim build-depends: ghc-prim

Is there a generic way to do this without impl ghc checks? Otherwise all these impl(ghc >= x) flag checks have to be changed to impl(ghc >= x) || impl(ghcjs >= y), not something I'd be looking forward to...

Also I personally don't really see it as a hack (of course I'm biased since I've been using it for a while). It just allows you to specify that "compiler x is based on compiler y", so that unless explicitly queried otherwise you can assume that flags for 'y' hold for 'x'.

luite

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel