Gearing up for a 1.18 release

[Luite Stegeman]

> 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:
-
https://github.com/ghcjs/cabal/commit/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d72#L15R109

Distribution.PackageDescription.Check uses it, but only for checking that
the base range is bounded, not with a real compiler, but with buildCompiler
with no version:
-
https://github.com/ghcjs/cabal/commit/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d72#L2L1240

buildCompilerId uses it (buildCompilerId is never used in Cabal,
cabal-install and hackage), a better change would be to find the
subcompiler if buildCompilerFlavor is GHCJS, but just adding Nothing makes
it do the right thing for all existing compilers:
-
https://github.com/ghcjs/cabal/commit/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d72#L1R137

The other changes are the direct intended changes: Updated flag resolution,
parsing/printing CompilerId, and getting the shared library filename from a
CompilerId
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20130826/ed6dad81/attachment.htm>