feat: add haskell-language-server 2.14.0.0 - #214
Merged
Conversation
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughAdds ChangesHaskell tooling packages
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested reviewers: Sequence Diagram(s)sequenceDiagram
participant BuildSpec
participant build.sh
participant Cabal
participant GHC
participant OUTPUT_DIR
BuildSpec->>build.sh: pass version and build inputs
build.sh->>Cabal: update package index and build executable
Cabal->>GHC: compile with sandbox toolchain
build.sh->>OUTPUT_DIR: install executable and libHS* libraries
BuildSpec->>OUTPUT_DIR: run haskell-language-server --version
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
This was referenced Jun 17, 2026
Contributor
There was a problem hiding this comment.
⚠️ Packaging and Operational Risk: Unsafe Dynamic Library Bundling
Hi @0chroma! Thanks for adding haskell-language-server.
During a review of the aggregated unstable build, we identified a significant operational and runtime risk in packages/haskell-language-server/build.sh:
The current script uses ldd to copy all linked dynamic libraries into $OUTPUT_DIR/usr/lib:
# Copy all shared Haskell libraries the binary depends on
for lib in $(ldd "$HLS_BIN" | grep '\.so' | awk '{print $3}'); do
if [ -n "$lib" ] && [ -f "$lib" ]; then
cp "$lib" "$OUTPUT_DIR"/usr/lib/
fi
doneWhy this is a problem:
- System Library Pollution:
lddreturns system-wide libraries such aslibc.so.6,libm.so.6,libpthread.so.0, and the dynamic linker. Copying these into/usr/lib/of the package packages them along withhaskell-language-server. - Dynamic Loader Collisions & Crashes: Distributing duplicate, potentially out-of-sync or incompatible core system GLIBC libraries in application packages is highly risky. It can cause severe runtime crashes (segmentation faults), loader conflicts, or even break the base system container's loader when installed.
- Bloat: It dramatically inflates the package size unnecessarily.
Recommended Fix:
Haskell executable targets built by Cabal statically link Haskell package dependencies by default. Standard external C library dependencies (such as GLIBC) should be resolved dynamically from the base system (since glibc is already in your runtime_deps).
Therefore, you can safely remove the library-copying block entirely. Here is the recommended clean build script:
#!/bin/bash
set -euo pipefail
# The source tarball is already extracted with strip_prefix, so we're in the source root
# Build HLS for the GHC version available in the sandbox
export GHC="$(command -v ghc)"
export CABAL="$(command -v cabal)"
# Update cabal package index
cabal update
# Build HLS with the available GHC version
cabal build \
--ghc-options="-j$(nproc)" \
exe:haskell-language-server
# Install to OUTPUT_DIR
mkdir -p "$OUTPUT_DIR"/usr/bin
# Find and copy the built binary from cabal's build directory
HLS_BIN=$(cabal list-bin exe:haskell-language-server)
cp "$HLS_BIN" "$OUTPUT_DIR"/usr/bin/And in packages/haskell-language-server/build.ncl, you can simplify the outputs definition by removing the libs entry:
outputs = {
hls = { glob = "usr/bin/haskell-language-server" } | OutputBin,
},
6 tasks
|
|
Add package for the Haskell Language Server (HLS), the official LSP implementation for Haskell. Builds from source using GHC + Cabal with dynamic linking, copying the binary and all required shared libraries via ldd dependency resolution. - Source: GitHub tag 2.14.0.0 with automatic extraction - Build deps: base, cabal, ghc - Runtime deps: glibc - Network access enabled for cabal dependency index updates - Includes standalone version check test
0chroma
force-pushed
the
add/haskell-language-server
branch
from
July 25, 2026 07:51
d71a920 to
f224abc
Compare
…/benchmark builds The HLS cabal.project ships with tests:True and benchmarks:True, which makes cabal resolve and compile test/benchmark deps for every transitive dependency — a major cost and failure surface for a 16+ minute build. Pass --disable-tests --disable-benchmarks to build only the executable. Also add alex, happy, and zlib as explicit build_deps. alex and happy are in ghc's build_deps (not runtime_deps), so they aren't injected into downstream builds — cabal would otherwise have to download and compile them from Hackage. zlib provides the C library needed by HLS's Haskell dependencies.
Without CABAL_DIR, cabal has no writable home for its config, package index, and build store in the sandboxed build environment — the most likely root cause of the 17-minute build failures. Every other Haskell package in the repo (tamarin-prover, stack) sets this; HLS was the only one that didn't. Also add --with-compiler for explicitness, -v1 for verbose output, and an error-capture block (matching tamarin-prover's pattern) that extracts the real compile/link error on failure instead of a bare "build failed" exit.
Replace --ghc-options="-j$(nproc)" (per-module GHC parallelism) with --jobs="$(nproc)" (per-package cabal parallelism). HLS is a massive project — running nproc GHC instances each with nproc internal module threads exhausts memory on the build host. Cabal-level parallelism compiles packages concurrently while keeping module compilation sequential within each package, matching the tamarin-prover build.
The HLS binary links against libgmp, libffi, and libz (GHC runtime dependencies), but runtime_deps only declared glibc — causing the missing-runtime-deps and standalone-test post-build checks to fail. Move zlib from build_deps to runtime_deps (runtime_deps are injected into the build env, so it covers both roles), and add gmp + libffi matching GHC's own runtime_deps.
Cabal installs alex/happy from Hackage as build-tool-depends, but the installed binaries link against GHC's shared libraries (libHSrts etc.) which aren't on the default library search path — so they fail to run and cabal reports "version could not be determined" (Cabal-1008). Two fixes: - Add GHC's libdir to LD_LIBRARY_PATH so cabal-installed build tools can actually execute - Pass --with-alex/--with-happy pointing at the pre-installed system versions so cabal uses those for version checks instead of its own broken copies
The system alex/happy were built with ghc-bootstrap 9.8.1, so their template files live in /usr/share/x86_64-linux-ghc-9.8.1/... — wrong GHC version. Passing --with-alex/--with-happy made cabal use those binaries, which then failed looking for templates in the 9.8.1 data dir. Remove the --with-* flags so cabal installs its own alex/happy from Hackage (built with 9.10.3, correct data dir). The LD_LIBRARY_PATH fix ensures those cabal-installed tools can actually execute.
alex and happy only captured their binary (usr/bin/alex, usr/bin/happy) as OutputBin — the template files that ./Setup copy installs to usr/share/x86_64-linux-ghc-<version>/... were discarded. Without the templates, the tools fail with "openFile: does not exist" when any downstream package uses them. Add a data OutputData (usr/share/**) to both alex and happy so the template files ship with the package. Then use --with-alex/--with-happy in the HLS build to point cabal at the pre-packaged versions instead of letting it download and build its own copies from Hackage — those copies were the source of the "version could not be determined" (Cabal-1008) failures. alex/happy are standalone code generators; they don't need to match the downstream GHC version, they just need their template files at the hardcoded path.
0chroma
marked this pull request as ready for review
July 25, 2026 12:40
github-merge-queue
Bot
removed this pull request from the merge queue due to no response for status checks
Jul 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Add the Haskell Language Server (HLS) v2.14.0.0 to the package registry, enabling Haskell LSP support for editors like Neovim, VS Code, and Emacs.
Context
HLS is the official Language Server Protocol implementation for Haskell, providing features like go-to-definition, type hover, code actions, and refactoring. It was missing from the registry, blocking Haskell development workflows.
Changes
packages/haskell-language-server/build.ncl— Build spec sourcing from GitHub tag 2.14.0.0 with automatic extractionpackages/haskell-language-server/build.sh— Build script using GHC + Cabal with dynamic linkingKey Implementation Details
cabal build exe:haskell-language-server(not prebuilt binaries per guidelines)lddto discover and copy all required shared Haskell libraries at runtime, avoiding static linking issues (Haskell libs aren't PIC-compatible)needs = { dns = {}, internet = {} }for Cabal dependency index updatesmin checkchecks pass, including standalone version testUse Cases
Testing
Summary by CodeRabbit
haskell-language-serverexecutable and required runtime libraries.