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 <dag.odenh...@gmail.com> 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 <stege...@gmail.com> 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 >> > _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
