search

matchwood / ghcjs-stack-dist

24 stars 7 forks source link

Why not ghcjs-stack? #5

Closed qrilka closed 7 years ago

qrilka commented 7 years ago

@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 https://github.com/tolysz/ghcjs-stack/issues/8

tolysz commented 7 years ago

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 commented 7 years ago

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

qrilka commented 7 years ago

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 commented 7 years ago

@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: https://github.com/tolysz/prepare-ghcjs/issues/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 commented 7 years ago

Opcodes, maybe they will be solved with https://github.com/ghcjs/ghcjs/issues/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 commented 7 years ago

@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 https://github.com/fpco/stackage/issues/2537 that GHCJS could be integrated only with lts-9

mihaimaruseac commented 7 years ago

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

qrilka commented 7 years ago

oh @mihaimaruseac thanks for the correction, sure

mihaimaruseac commented 7 years ago

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

tolysz commented 7 years ago

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 commented 7 years ago

Closing in favor of https://github.com/ghcjs/ghcjs-base/issues/93