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
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
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,
I'm not worried about these packages, but about the Cabal code base itself.
The Cabal code base hardly creates CompilerId directly, in almost all cases
the change is ignoring the third field. This is where CompilerId is created:
All existing flavours add Nothing, 6x one-line change:
-
Hi all,
We're close to a new release of Cabal/cabal-install and I'd appreciate some
help in testing the new release. To install the release candidate, simply
run:
cabal install http://johantibell.com/files/Cabal-1.18.0.tar.gz
http://johantibell.com/files/cabal-install-1.18.0.tar.gz
Please try
