This also requires a bump to lsp-test to fix a test, and drops the
trick that the wrapper tests used to find the wrapper executable since
it was just confusing
Update ghcide to obtain the GHC lib dir at runtime, rather than at compile time with ghc-paths. This means that the binaries can be moved about since the lib dir is obtained on the fly
Share the exe/main.hs logic between ghcide and hls: the session setup logic which previously took up most of exe/main.hs now resides inside the ghcide library, and is used by both ghcide and hls's executables
Add a --project-ghc-version option to the wrapper which spits out the project's ghc version to stdout. This is useful for the vscode extension which can then use it to download the corresponding version of binary that the wrapper would have otherwise attempted to launch
Make the wrapper check to see if the correct tool is installed beforehand. For example, if it detects a stack project but stack isn't on the path, it will report an error then and there, rather than having hls/ghcide confusingly fail later on. The vscode extension uses this new error message as well to provide a pop up message linking the user to a website to install the missing tool
Remove cabal-helper from the wrapper, so that the implicit cradle logic is the same between ghcide/hls/hls-wrapper
And of course, add a GitHub action workflow that runs whenever a release is created on GitHub that builds static binaries on Linux, and distributable enough binaries on macOS and windows. This is documented a bit more in docs/releases.md
* WIP
* WIP 2
* WIP 3
* WIP 4
* WIP 5
* WIP 6
* WIP 7
* WIP 8
* WIP 9 Use patched hie-bios to get libdir dynamically
* Try building the wrapper
* Try to fix build_wrapper env variable not being picked up
* Try again
* Give up on the env var idea
* Try out static optimised builds?
* Try squashing the working dir
* Woops
* Try squashing the builddir
* Try going into the parent directory
* Radical approach - don't use such a long name for the wrapper
* Use dist-binary flag
* Debug why floskell fails to build on windows
* haskell-language-server => hls on CI
I hate that I have to do this
* Employ extreme path saving measures
* sed time :(
* Try making sed command portable
* Compress artefacts
* Tidy up wrapper logging
* Use version checking logic in hie-bios
* Add documentation on the releases process
* Remove unused code
* Append .exe to windows binaries
* Try out building remaining supported ghc configurations
* Add wrapper tests and update hie-bios
* Use index timestamp that exists on hackage
Fixes warning
* Update hie-bios
* Update hie-bios
* Try building windows jobs on -j1
* Skip windows 8.8.2
* Update ghc-check to use hie-bios runtime ghc libdir
* Upload binaries as an artifact too
* Try flicking on enable-executable-static
I don't expect this to work, puffnfresh has already tried this and had
to fork ghcup
* Fix artifact upload
* Update to latest ghcide and reuse loadSession
* Check if the tool is installed in --project-ghc-version in the wrapper
* Fix wrapper tests by copying to temporary directory
* Try caching
* Tidy up and switch back to cabal helper implicit cradle
* use split sections
* Remove cabal-helper and replace it with hie-bios implicit logic
The cabal-helper cradle was only used by the wrapper for detecting the
project GHC version in the absence of an explicit hie.yaml file, whilst
ghcide itself used the hie-bios implicit cradle logic. This brings the
two in sync so the wrapper should behave more predictably now.
* Undo agpl common stanza change
* Add release number
Co-authored-by: amesgen <amesgen@amesgen.de>
First pass only, need to (re-)enable tests, and find a way of selecting between
multiple formatters. Apart from only installing a single formatter plugin.
A kind of "hello world" LSP plugin.
Tested with emacs lsp-mode by setting "Lsp Haskell Process Path Hie"
to `ide`, and clearing out the "Lsp Haskell Process Args Hie".
