hi all, We're readying the GHCJS [1] compiler for the first release, to coincide with GHC's 7.8.1 release. For now, GHCJS is a stand-alone executable that uses the GHC API and manages its own package database. We've been maintaining a Cabal patch with the intention to get it merged in 1.18, but now that release appears to be earlier than I expected (thanks Carter for warning me!) The current diff is here (the js-sources / extra-js-files field additions would be left out for 1.18, and some of the Distribution.Simple.GHC module changes can be cleaned. Give me a few days if you want a full patch for review): https://github.com/ghcjs/cabal/compare/ghcjs I'm not sure if it's still feasible to get the whole thing in (I have time to hack on it the coming weeks and can discuss at ZuriHac) 1.18, but if not, there are some very small parts that change the API a bit, that could perhaps go in 1.18, postponing full GHCJS support to 1.18.1 or similar. Does that sound reasonable? Overview of the changes: 1. CompilerId gets an extra field, indicating that compiler x is based on compiler y. Both compilers have their own version. impl(x >= x-version), impl(y >= y-version) flags would both be true for this flavor. (This is the public API change). GHCJS is added as a compiler flavor 2. Support for the GHCJS flavor is plumbed throughout Cabal 3. The Distribution.Simple.GHC module exports internal functions, some of those are modified so the program can be passed in explicitly. For most things, the Distribution.Simple.GHCJS module calls back to the GHC module pretending to have the version of the underlying GHC. 1. changes existing API a tiny bit, so that would be nice to go in 1.18 if still possible. 3. is a bit messy, but doing it this way appears to avoid by far the most code duplication. Perhaps some restructuring of the GHC module would make it better, then it could be done without touching exported API. I'd be happy to hear comments or suggestions and clean it up a bit. luite [1] https://github.com/ghcjs