Consider add an option to build hls from source (like ghc)

• As hls is very tied to the ghc version used in the projects and the os where it is being used
• And cause we are suggesting built it from source to workaround several issues (th problems in macos, support for different linux versions and flavours, like arch)

(proposed by mallory in the fp discord server)

---

https://github.com/haskell/haskell-language-server/issues/2092

changed the description

That could be possible. A few concerns/questions:

1. It's one build per GHC version, right?
2. If the build system of HLS changes a lot, this will be a maintenance challenge, as every such change requires a new ghcup release.

@maerwald I think it would be reasonable to ask the HLS team for help regarding build system changes, if it changed one day.

if the build system of HLS changes a lot, this will be a maintenance challenge, as every such change requires a new ghcup release.

• The build system had no changes in years (no promises though, Murphy is listening us)
  • Sure we would help if it changes, as pointed out by @Kleidukos
• It uses a cabal/stack script but basically it does a cabal install -w $ghcVersion && cp /path/to/haskell-language-server /path/to/haskell-language-server-${ghcVersion} (cp, ln or whatever)
  • I think using the script would be the straight way, as it would be used as a layer to not impact ghcup if something changes underneath

It's one build per GHC version, right?

yeah

What happens if a user tries to install for an unsupported GHC version?

Error messages:

• If there are not supported ghc version in PATH:

No ghc installations found in $PATH.
The script requires at least one ghc in $PATH
  to be able to build haskell-language-server.

• If you try to install it for a supported but not in PATH ghc version

> cabal-hls-install hls-8.8.3

Error when running Shake build system:
  at want, called at src\Development\Shake\Internal\Args.hs:83:67 in shake-0.19.
5-c3332275f07f0a7bc1fcc17f8e9592ecf34322bb:Development.Shake.Internal.Args
* Depends on: hls-8.8.3
  at error, called at src\Development\Shake\Internal\Rules\File.hs:179:58 in sha
ke-0.19.5-c3332275f07f0a7bc1fcc17f8e9592ecf34322bb:Development.Shake.Internal.Ru
les.File
* Raised the exception:
Error, file does not exist and no rule available:
  hls-8.8.3

• tbh error messages are quite bad, the first one should be

No supported ghc installations found in $PATH.
The script requires at least one supported ghc in $PATH
  to be able to build haskell-language-server.
GHC supported versions: 8.6.4, 8.6.5, ...

• and the second one should be replaced with a proper error message

What happens if a user tries to install for an unsupported GHC version?

@maerwald even if we improve error messages, could ghcup check if the ghc version is installed before build hls (optionally installing it as previous step)?

could ghcup check if the ghc version is installed before build hls (optionally installing it as previous step)

That knowledge can only be put in haskell source code currently and as such is unergonomic. We also rely on error messages from GHC on ghcup compile ghc.

Wrt the second point: ghcup doesn't automatically install stuff, even on ghcup compile ghc, which needs a bootstrap GHC already installed.

I believe this follows ghcup philosophy of least surprise/maximum control. We don't do stuff behind the users back.

So the interface would mostly follow what ghcup compile ghc currently is, allowing to provide even arbitrary paths to a GHC binary for building.

---

For the interactive TUI, we could ask the user whether they want the missing GHC installed. TUI is a totally different interface, in theory.

I see, the unique caveat i can think off is the hls build script should keep error relatively generic and not sure if they will be helpful in the ghcup context.

I believe this follows ghcup philosophy of least surprise/maximum control. We don't do stuff behind the users back.

I was thinking in ask user before doing it

That knowledge can only be put in haskell source code currently and as such is unergonomic. We also rely on error messages from GHC on ghcup compile ghc.

agree

let's see if we can improve error messages and make them be helpful in the context of a ghcup installation (i dont see a direct mention to ghcup appropiate upstream)

I was thinking in ask user before doing it

The CLI interface is non-interactive.

The TUI isn't.

added typeimprovement label

I tried today and I can't even tell the HLS build system where to install files to. It reads the cabal config via cabal-install-parsers manually and doesn't accept overrides.

Another problem is that findInstalledGhcs checks for stack-<ghcver>.yaml to figure out which GHCs are supported. As such, you currently can't build hls-8.10.6 without modifying the source tarball.

changed the description

changed milestone to %0.1.17

Done

closed