Why not ghcjs-stack?

[qrilka]

@matchwood at least according to stack docs @tolysz is doing main effort of supporting GHCJS with stack and there is https://github.com/tolysz/ghcjs-stack
So it makes me wonder why this repo is a separate effort and there is no lts-8 at https://docs.haskellstack.org/en/stable/ghcjs/
Also see tolysz/ghcjs-stack#8

[tolysz]

I am fine with more people doing what I am doing :)
The main issue is we need to have someone stepping up as a project/release manager for GHCJS (for each of the compiler branches).
I am blocked by a couple of things - (ignoring time obviously ;) ) - ghcjs need to have a few more opcodes; base- needs to be ported to ghcjs, aeson in lts8 is still too old, other packages from boot which I did not to while doing the previous...

[qrilka]

@tolysz more people is always good of course but it's better to unite forces if there are any :)

[qrilka]

and regarding base and opcodes - are there any details somewhere? Some issue? It's a bit surprising to have something like that on a GHC switch from version 8.0.1 to 8.0.2

[matchwood]

@qrilka Agreed that we should unite forces where possible! I am aware of @tolysz 's work (https://github.com/tolysz/prepare-ghcjs is where his more recent work is I think) - and in fact I dicussed my attempts to get things working with him in that repo: tolysz/prepare-ghcjs#6 . I've also asked whether there is any interest in this in the stack Google group https://groups.google.com/forum/#!topic/haskell-stack/CMvbzhb2zdw but received no responses, hence my decision to simply throw this up on Github.

@tolysz I'd be interested in the issues with base and opcodes as well, if you could link an issue or similar that would be great!

[tolysz]

Opcodes, maybe they will be solved with ghcjs/ghcjs#580

The real effort should go into porting all patches into the packages, rather than having some parallel universe of modified things.

In the ideal world we should contribute against ghcjs-boot; having it aligned to each lts as tag; then making a distribution will be as simple as checking the right tag.

[qrilka]

@matchwood @tolysz what about using 1 repo to track GHCJS+stack integration? And mark other ones as deprecated by that "chosen" one.
BTW it looks from commercialhaskell/stackage#2537 that GHCJS could be integrated only with lts-9

[mihaimaruseac]

Did you want to say commercialhaskell/stackage#2532 instead of 2537?

[qrilka]

oh @mihaimaruseac thanks for the correction, sure

[mihaimaruseac]

Just wanted to have the reverse link on the proper issue. Thanks

[tolysz]

I really think the discussion should happen at "ghcjs-base", as this will focus the effort;
Now, we need to have some RELEASE MANAGERS to manage lts branches.
Everything else is just a duplication of work.

stack should already be able to take the appropriate command line arguments to specify which branch to use for booting!

[qrilka]

Closing in favor of ghcjs/ghcjs-base#93