@Ericson2314 What's the purpose of this? Frankly I kinda wish bootPkgs weren't passed thru, since the boot GHC should be considered irrelevant to the GHCJS.

@Ericson2314 if it's supposed to indicate the version of GHC that this GHCJS represents, I think it's a coincidence that this works right now. There's no fundamental reason GHCJS 8.4 can't be built with GHC 8.2, I think it's just some buggy things preventing that from working right now.

@ElvishJerricco so first I was thinking exactly what you are. (Indeed I like the way your ghcjs-ng uses bootPkgs and separates booting from normal cabal2nix derivation a lot better.) But then I remembered that GHCJS is both using that GHC's executable component to build itself, and linking its library component for the early compiler stages. So insofar that it inherits behavior from the GHC library, it's not a coincidence.

Eventually with butter GHCJS (or webasm ;)) we'll be better, but I don't think it's worth messing with the boot process to get separate GHC exe and GHC library derivation dependencies.

and linking its library component for the early compiler stages

Huh? Not in 8.2 / 8.4. These versions brought the GHC source in-tree as a submodule and builds the GHC modules it uses itself. I believe you could literally build GHCJS 8.4 with GHC 8.2 right now, if you worked out a couple bugs, and you would get actual GHC 8.4 behavior.

Oh my bad. Well then let's redefine them for the latter two then. I made this for the earlier two since they had very different version numbers, and then coppied it to the latter two without checking so I could always get the version from GHCJS the same way.