GHCJS support for Cabal

[Johan Tibell]

Hi Luite,

First let me say I'm excited about GHCJS and like for us to support it in Cabal.

As for the actual changes:

(1) feels like an implementation detail of GHCJS that has been
promoted into something everyone will have to deal with. I would like
us to give this design some more thought (preferably with input from
Duncan) before we merge these changes.

(2) is fine.

I haven't looked in detail at (3), but improving code reuse seems
reasonable. Perhaps we should move the shared functions to
D.S.GHC.Base or something to not complicate the API offered by
D.S.GHC.



On Wed, Aug 21, 2013 at 2:01 AM, Luite Stegeman <stegeman at gmail.com> wrote:
> 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
>
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel
>