GHCJS support for Cabal

[Luite Stegeman]

>
> (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.
>

It's not so much an implementation detail of GHCJS itself, but more a side
effect of many people using impl(ghc) flags in their packages to check
whether the compiler supports some particular feature. We could leave it
out, but then many packages would have to be updated to duplicate the impl
check (or replace it)

The effect on the Cabal lib itself is minor, and the impl(ghcjs) flag would
be false for anyone not using ghcjs.



> (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.


I'm testing a new version that requires no changes to the code in the GHC
module, other than some exports, so don't look at this in detail yet (like
i said yesterday, it's ready today, which is, before i go to bed)

luite
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20130823/94657566/attachment.htm>