Gearing up for a 1.18 release

[Luite Stegeman]

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
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20130826/1fb9b4b9/attachment.htm>