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 <stege...@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.tib...@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.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
