I don't know very much about GHCJS, so I'm hesitant to merge this without at least a look-over from someone more knowledgeable about GHCJS.

Off the top of my head, I think @Ericson2314 and @angerman are both using GHCJS at their respective companies, so maybe they'd be able to give a good review.

Also, @dfordivam we have a Hydra jobset for Haskell in pkgs/top-level/release-haskell.nix. You might not want to do it in this PR (since it is already long), but at some point you may want to send a PR adding GHCJS to this jobset. If you do this, you'll get pinged on our haskell-updates PRs if GHCJS ever stops compiling. Here's an example of people being pinged for packages that have stopped compiling: #136589 (comment)

@dfordivam Ah, one last thing. Can you set the base branch to the haskell-updates branch instead of main for this PR? We generally try to merge all Haskell-related changes into haskell-updates.

Oh, and maybe ghcjs-ng -> ghcjs since the old GHCJS is now many years long gone?

I checked, and that shouldn't cause collisions on 21.05 or 20.09 either, where we might want to backport, so yes let's do that rename.

ghcjs is quite big and 2.9GB over the output limit on Hydra at the moment, so we can't provide binary cache for it.

Any ideas how we can cut this down? Building the libraries separately and individually could be a solution, but not sure if it is even possible.

> du --max-depth 2 -h /nix/store/jnlca2nvk61mxr6x0pgqchfnrfnzwsjd-ghcjs-8.10.7/
57M	/nix/store/jnlca2nvk61mxr6x0pgqchfnrfnzwsjd-ghcjs-8.10.7/bin
20M	/nix/store/jnlca2nvk61mxr6x0pgqchfnrfnzwsjd-ghcjs-8.10.7/lib/ghcjs-8.10.7
3.8G	/nix/store/jnlca2nvk61mxr6x0pgqchfnrfnzwsjd-ghcjs-8.10.7/lib/js-ghcjs-ghcjs-8.10.7-ghc8_10_7
3.8G	/nix/store/jnlca2nvk61mxr6x0pgqchfnrfnzwsjd-ghcjs-8.10.7/lib
112K	/nix/store/jnlca2nvk61mxr6x0pgqchfnrfnzwsjd-ghcjs-8.10.7/share/doc
112K	/nix/store/jnlca2nvk61mxr6x0pgqchfnrfnzwsjd-ghcjs-8.10.7/share
3.9G	/nix/store/jnlca2nvk61mxr6x0pgqchfnrfnzwsjd-ghcjs-8.10.7/

Building the libraries separately is always something I'm keen to do in general. I'll try to see if we can investigate.

@dfordivam did report that the output was significantly smaller on their machine, so I'm a bit confused what exactly is going wrong on Hydra and my machine.

@sternenseemann I just managed to build ghcjs on Darwin, and the output turns out to be 3.9G

3.9G	/nix/store/d9frl6sh7iydrgrqz9hgxv1fvkhjgcff-ghcjs-8.10.7

Given this I looked back at the linux machine and figured out that my number were wrong due to zfs compression. This is the real value..

$ du -h --apparent-size  /nix/store/vqw115sfnwl3y514shqc0malc1aaqgfj-ghcjs-8.10.7/
3.9G    /nix/store/vqw115sfnwl3y514shqc0malc1aaqgfj-ghcjs-8.10.7/

So this is in line with the 4G llvm-aarch64 build we had? I hope that the ghcjs-in-ghc will be smaller, as it will eventually drop some packages from the rather large dependency closure of ghcjs.

@angerman I don't think ghcjs' (Haskell) dependency closure is the problem (if you mean that). The problem is rather the /lib/js-ghcjs-ghcjs-8.10.7-ghc8_10_7 (3.8 GB) directory which is probably necessary as it contains the bundled packages for the compilation target.

@angerman yeah we should very soon ™ be able to build GHC itself, RTS, base by themselves for regular GHC, and I hope that will be the case for GHCJS too.