> 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
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
