Gearing up for a 1.18 release

[Johan Tibell]

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.odenhall at 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 <stegeman at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/cabal-devel
>>
>