Gearing up for a 1.18 release

[Johan Tibell]

I'd like for Duncan to comment on this.

> If there's a way to achieve this without changing CompilerId, that would be great. As for the CompilerId change itself:
>
> There are 11 packages on hackage that appear to use the CompilerId constructor (archlinux, cab, cabal-debian, cabal-db, cabal2nix, cabal-ghci, cabal-install-bundle, cblrepo, ghc-mod, hackport, hoogle)

I'm not worried about these packages, but about the Cabal code base itself.


On Mon, Aug 26, 2013 at 1:00 PM, Luite Stegeman <stegeman at gmail.com> wrote:
> To be honest I think that's a much bigger hack than what I originally
> proposed. The point of the sub/super compiler CompilerId change is that both
> parts can have their own version range. For example GHCJS is currently at
> version 0.1.0, GHC at 7.6. While currently GHCJS can only be built against
> HEAD, that could change in the future (we used to have a version compatible
> with both 7.4 and 7.6), and one could want checks like this:
>
> impl(ghcjs >= 0.1) && impl(ghc < 7.10)
>
> I think this could also come in handy with Roman's haskell-suite compiler
> flavour, which makes it easy to make customized compilers. If you make
> something based on GHC it would be useful to be able to specify that, so you
> can support packages that depend on impl(ghc) checks. With this CompilerId
> change, that can be implemented for the HaskellSuite flavour by just giving
> the user a way to specify the compiler name/version.
>
> If there's a way to achieve this without changing CompilerId, that would be
> great. As for the CompilerId change itself:
>
> There are 11 packages on hackage that appear to use the CompilerId
> constructor (archlinux, cab, cabal-debian, cabal-db, cabal2nix, cabal-ghci,
> cabal-install-bundle, cblrepo, ghc-mod, hackport, hoogle)
>
> I'd be happy to send all of them a pull req. For other projects (not on
> hackage), I think that with some comments/Haddock the CompilerId type they
> can be quickly guided towards the right change (usually ignoring the field
> or adding Nothing)
>
> luite
>
>
> On Mon, Aug 26, 2013 at 3:39 PM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
>>
>> 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
>> >>
>> >
>
>