Skip to content

Prepare 1.6.1.1 (only hackage release) #2681

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Feb 2, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion .github/actions/setup-build/action.yml
Original file line number Diff line number Diff line change
Expand Up @@ -63,10 +63,19 @@ runs:
fi
shell: bash

# The default build for haskell-language-server executable is dynamic for linux and macOS
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, thank you.

# to get a executable which works for Template Haskell
# However we continue providing full static executables in releases so we have to disable it
# *for all workflows*, including test, flags and release builds
- name: Disable -dynamic
run: |
echo -e "package haskell-language-server\n flags: -dynamic" >> cabal.project.local
shell: bash

- if: inputs.os == 'Windows' && inputs.ghc == '8.8.4'
name: (Windows,GHC 8.8) Modify `cabal.project` to workaround segfaults
run: |
echo -e 'package floskell\n ghc-options: -O0' >> cabal.project.local
echo -e 'package floskell\n ghc-options: -O0' >> cabal.project.local
shell: bash

# Shorten binary names as a workaround for filepath length limits in Windows,
Expand Down
5 changes: 0 additions & 5 deletions .github/workflows/build.yml
Original file line number Diff line number Diff line change
Expand Up @@ -48,11 +48,6 @@ jobs:
echo "tests: false" >> cabal.project.local
echo "benchmarks: false" >> cabal.project.local
- name: Disable -dynamic
run: |
echo "package haskell-language-server" >> cabal.project.local
echo " flags: -dynamic" >> cabal.project.local
- uses: ./.github/actions/setup-build
with:
ghc: ${{ matrix.ghc }}
Expand Down
13 changes: 13 additions & 0 deletions ChangeLog.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,18 @@
# Changelog for haskell-language-server

## 1.6.1.1 (*only hackage release*)

- Release to update haskell-language-server.cabal in hackage, setting the build for the executable component as dynamically linked
- The motivation is build by default a hls executable which works for Template Haskell
- This doesn't need a full release cause it does not affect release executables which continue being fully static

### Pull requests merged for 1.6.1.1

- Prepare 1.6.1.1 (only hackage release)
([#2681](https://github.com/haskell/haskell-language-server/pull/2681)) by @jneira
- Add the -dynamic flag and update build instructions
([#2668](https://github.com/haskell/haskell-language-server/pull/2668)) by @pepeiborra

## 1.6.1.0

This is a bug fix release to restore a fully statically linked haskell-language-server-wrapper executable.
Expand Down
10 changes: 5 additions & 5 deletions docs/troubleshooting.md
Original file line number Diff line number Diff line change
Expand Up @@ -160,27 +160,27 @@ The server log will show which cradle is being chosen.

Using an explicit `hie.yaml` to configure the cradle can resolve the problem, see the [configuration page](./configuration.md#configuring-your-project-build).

### Static binaries and template haskell support
### Static binaries

Static binaries use the GHC linker for dynamically loading dependencies when typechecking TH code, and this can run into issues when loading shared objects linked against mismatching system libraries, or into GHC linker bugs (mainly the Mach linker used in Mac OS, but also potentially the ELF linker).
Static binaries use the GHC linker for dynamically loading dependencies when typechecking Template Haskell code, and this can run into issues when loading shared objects linked against mismatching system libraries, or into GHC linker bugs (mainly the Mach linker used in Mac OS, but also potentially the ELF linker).
Dynamically linked binaries (including`ghci`) use the system linker instead of the GHC linker and avoid both issues.

The easiest way to obtain a dynamically linked HLS binary is to build HLS locally. With `cabal` this can be done as follows:

```bash
cabal update && cabal install pkg:haskell-language-server"
cabal update && cabal install pkg:haskell-language-server
```

If you are compiling with a ghc version with a specific `cabal-ghc${ghcVersion}.project` in the repo you will have to use it. For example for ghc-9.0.x:

```bash
cabal update && cabal install pkg:haskell-language-server --project-file=cabal-ghc90.project"
cabal update && cabal install pkg:haskell-language-server --project-file=cabal-ghc90.project
```

Or with `stack`:

```bash
stack install haskell-language-server --stack-yaml=stack-${ghcVersion}.yaml"
stack install haskell-language-server --stack-yaml=stack-${ghcVersion}.yaml
```

You also can leverage `ghcup compile hls`:
Expand Down
2 changes: 1 addition & 1 deletion haskell-language-server.cabal
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
cabal-version: 2.4
category: Development
name: haskell-language-server
version: 1.6.1.0
version: 1.6.1.1
synopsis: LSP server for GHC
description:
Please see the README on GitHub at <https://github.com/haskell/haskell-language-server#readme>
Expand Down