install.hs ignores -j1 option despite --help usage

[ulidtko]

Hi!

When compiling from source on a moderately-powered (4-core but RAM-limited) machine, managing GHC memory usage becomes an obstacle. With some particularly heavyweight dependencies (ghc-lib, Cabal), the ghc process easily reaches 2 GiB usage.

That's not an issue in itself — my usual workaround is disabling build parallelism via -j1 (on top of shutting down everything else running on the system except the bare minimum).

The issue is, that ./install.hs claims to support -j1 but in fact doesn't:

$ ./install.hs --help | grep CPU
  -j[N], --jobs[=N]           Allow N jobs/threads at once [default CPUs].

This is easily checked by running with -j1 and observing the build log (it shows compiling multiple packages at once) or the process tree.

---

My environment

$ haskell-language-server --probe-tools
haskell-language-server version: 1.1.0.0 (GHC: 8.6.5) (PATH: /home/ulidtko/.local/bin/haskell-language-server) (GIT hash: f1c096927186a93d8e3ccd4fe8385cc1b070350b)
Tool versions found on the $PATH
cabal:		3.2.0.0
stack:		2.5.1
ghc:		8.10.4

OS: ArchLinux

lsp-client: neovim

Steps to reproduce

• In HLS tree, run ./install.hs hls-8.6.5 -j1

Expected behavior

• -j1 is respected and the build becomes single-threaded.

Actual behavior

• -j1 is ignored and the build runs $ncpus GHCs.

[jneira]

hi, thanks for the bug report.
I am afraid that we have two phases: the first one builds and run the script and -j1 will affect only that phase.
Then the script, at runtime, makes one or more calls to stack or cabal to build hls itself. None of the usual args passed to the first phase are threaded to the second one.
The workaround is set the option in the appropiate stack-${ghcVersion}.yaml of hls itself (for stack is https://docs.haskellstack.org/en/stable/yaml_configuration/#jobs) or add it to cabal.project (https://cabal.readthedocs.io/en/3.4/cabal-project.html#cfg-field-jobs)

[ulidtko]

Ah yes, I can see how that makes sense. The workaround is decent too, I'll try it on the next upgrade. Thanks @jneira !

[jneira]

You are welcome.
The proper fix would be make the script accept a custom argument to accept params to be passed to runtime stack/cabal calls, like: stack run ./install.hs -- --build-arguments="-j1" or something alike.
So i am gonna to keep it open in case someone want to make a pr.

[michaelpj]

install.hs is dead.