Support for GHCJS-specific packages

[mgsloan]

I don't think it's the right time yet to add GHCJS support to stackage. However, once there's been a release and things have stabilized around that, it will likely make sense to have snapshots specific to GHCJS. Here are my current thoughts on how to do this:

I've recently realized that GHCJS can indeed theoretically compile all of stackage. C FFI calls turn into javascript function calls, and the google closure compiler can warn about the ones that don't have definitions.

This means that we may be able to avoid having a separate series of GHCJS specific snapshots, which was what I thought would need to happen. However, we would also want to be able to add packages which only compile with GHCJS. Would it be ok to include GHCJS-only packages in stackage? It would seem to violate the guarantee that "everything in this list builds with GHC".

It seems quite possible to automatically determine if a package requires GHCJS. I think we can make it conventional for GHCJS-only packages to have the following in their library stanza:

if !impl(ghcjs)
  buildable: False

I've been discussing this stuff with Hamish Mackenzie on #ghcjs IRC, and he asked the question "How does stackage handle packages that only work on some OSs?" AFAIK stackage doesn't make a distinction here. But if it did, it makes sense to use the same distinction that's used for GHCJS-only packages.

[snoyberg]

We have the concept of packages which are in Stackage, but not built by
Stackage, which we use for Mac and Windows packages. We could theoretically
do the same for GHCJS packages.

On Sun, Oct 18, 2015 at 8:50 AM, Michael Sloan notifications@github.com
wrote:

I don't think it's the right time yet to add GHCJS support to stackage.
However, once there's been a release and things have stabilized around
that, it will likely make sense to have snapshots specific to GHCJS. Here
are my current thoughts on how to do this:

I've recently realized that GHCJS can indeed theoretically compile all of
stackage. C FFI calls turn into javascript function calls, and the google
closure compiler can warn about the ones that don't have definitions.

This means that we may be able to avoid having a separate series of GHCJS
specific snapshots, which was what I thought would need to happen. However,
we would also want to be able to add packages which only compile with
GHCJS. Would it be ok to include GHCJS-only packages in stackage? It would
seem to violate the guarantee that "everything in this list builds with
GHC".

It seems quite possible to automatically determine if a package requires
GHCJS. I think we can make it conventional for GHCJS-only packages to have
the following in their library stanza:

if !impl(ghcjs)
buildable: False

I've been discussing this stuff with Hamish Mackenzie on #ghcjs IRC, and
he asked the question "How does stackage handle packages that only work on
some OSs?" AFAIK stackage doesn't make a distinction here. But if it did,
it makes sense to use the same distinction that's used for GHCJS-only
packages.

—
Reply to this email directly or view it on GitHub
#8.

[mgsloan]

I think that's quite sensible, great! This means that supporting GHCJS on stackage + stack will consist of:

• Adding the ghcjs package once it's released.
• Modifying how stack's GHCJS support works. I've opened an issue here: commercialhaskell/stack#1190

[mgsloan]

Closing this issue, since it seems like we might be able to add support for GHCJS packages with no further work on stackage itself.