GHCJS integration with stack LTS

[qrilka]

Following @tolysz proposal this is meant to be main ticket to discuss the way how to organize proper GHCJS integration with stack and to minimize obstacles to do that for future GHCJS or stackage LTS releases. As I'm not among maintainers of GHCJS or stackage I don't quite understand the details of such an effort so I'd be glad to here some proposals from @tolysz, @hamishmack and others and also I'd be glad to help.

[matchwood]

@qrilka Thanks, I completely agree with @tolysz that my stop-gap repo was not the best place for this discussion!

GIven the issues with lts-8, aeson in particular, I think it makes sense to ignore it, and simply target lts-9 (with a practical long term strategy, as suggested by @tolysz).

I would be willing to volunteer (given time constraints naturally) to be involved in this in some form.

Having gone through the pain of building ghcjs mutliple times with different patches and so forth, I agree with @tolysz that the long term maintainable solution is to integrate ghcjs patches into the upstream packages, rather than using the current diff strategy.

For this to work we'll presumably need someone invested in ghcjs to be responsible for every package used by ghcjs-boot. So perhaps one of the things we should discuss is assigning packages to those willing and able to help in this project?

I'm still not 100% sure what @tolysz is suggesting wrt lts branches, but it seems that a similar process has to happen for that.

[hamishmack]

I don't use stack myself.

I use a nix-shell to build and install everything I depend on and inside that nix-shell I use cabal new-build to build the stuff I am working on. This is a fantastic combination, nix gives you complete control over your dependencies (including native ones) and cabal new-build gives fast build times even when working on multiple packages.

In case you are wondering "why not use stack inside a nix-shell"? The problem is that stack likes to be told what your environment is rather than discovering it from the nix-shell (using ghc-pkg listand pkg-config). You can see examples of this here and here.

If you have not tried a nix-shell and cabal new-build together I strongly recommend you give it a go. We should really have some minimal example somewhere, but reflex-platform works well (you don't have to use reflex inside the the shell if you don't need it).

BTW I actually run Leksah inside the nix-shell and let it run cabal new-build for me.

[tolysz]

@matchwood GHCJS evolves all the time, and if we want to have packages working with a newer version of ghcjs we need to update them. So far I was freezing ghcjs with some packages when I was rebuilding the boot, but we might as well not freeze it, therfore they need to be separate branches.

https://github.com/commercialhaskell/stack/blob/master/ChangeLog.md (still unreleased) we can boot ghcjs via stack from any git tag.

I guess it does not matter if we use nix or stack as we still need to fix the base packages!

[hamishmack]

I guess it does not matter if we use nix or stack as we still need to fix the base packages!

Yes we should not neglect fixing upstream (stack and nix both make it easy to forget). I see reflex-platform is currently using @luigy's ghcjs-base in default.nix. Making sure everything in that is merged into ghcjs-base might be a good place to start.

[sigrlami]

I'm trying to continue work @tolysz doing. While I managed to build GHCJS with latest lts-8.21. I have problem building for reflex-frp where ghcjs-prime needed for ghcjs-base. @mgsloan is there any way to hook from stack ghcjs-prime included in ghcjs itself rather that package https://github.com/ghcjs/ghcjs-prim which I think is deprecated, but still in use?

[sigrlami]

Figured it out. Like this

- location: 
    git: https://github.com/ghcjs/ghcjs
    commit: 39eaf2e5a5305e421ba20467808d7a0d621d4bf3
  subdirs:
    - lib/ghcjs-prim

[nomeata]

Until this package is in Hackage, I created a hackage overlay with this package: http://hackage-ghcjs-overlay.nomeata.de/