Gearing up for a 1.18 release

Dag Odenhall dag.odenhall at
Mon Aug 26 12:09:02 CEST 2013

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

Just my two cents. :-)

On Sun, Aug 25, 2013 at 6:53 PM, Luite Stegeman <stegeman at> 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 at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the cabal-devel mailing list