Remove dead GHCJS import + fix stale binDirectoryFor call#359
Open
angerman wants to merge 123 commits into
Open
Remove dead GHCJS import + fix stale binDirectoryFor call#359angerman wants to merge 123 commits into
angerman wants to merge 123 commits into
Conversation
- Remove QualifiyOptions Remove QualifyOptions by setting qoSetupIndependent to be always true (the current default) and qoBaseShim false (this must have been just a hack of some sort).
…ry, pkgsUseProfilingLibrary, pkgsUseProfilingLibraryShared We do not want to check the compiler.
It is not very useful.
…build dependencies
…antiatedWith from ElaboratedConfiguredPackage to ElaboratedComponent Instantiation only makes sense for components.
add stages list
…g jsem This is a user problem. User should not enable jsem on a compiler that does not support it. This change also avoid us to pass the compiler all the way down. A better approach to restore this functionality would be to defer the application of the parallel strategy.
Merge fromSolverInstallPlan and fromSolverInstallPlanWithProgress.
This reverts commit 5573dea.
This reverts commit 7c1cd10.
This reverts commit bd93810.
Restore the file monitor mechanism to track already-built packages, using the same approach previously established for in-place builds. This also replaces `phaseImprovePlan`, which improved the elaborated plan by matching source packages against installed store entries. Key changes: - Restore file monitor updates in `buildAndInstallUnpackedPackage`: source files, inplace dependency build cache files, and registration - Simplify `BuildStatusBuild` by dropping the `Maybe InstalledPackageInfo` field, which is now tracked via the registration file monitor instead - Simplify `checkPackageFileMonitorChanged` accordingly - Remove `phaseImprovePlan` and store entry matching from the plan rebuild phase; `rebuildInstallPlan` now returns a 4-tuple instead of 5
…race When two stages of the same package (e.g. build: and host: in cross- compilation) are scheduled concurrently, both threads can observe the unpacked source directory as non-existent and race to extract the tarball. The second extraction overwrites the first mid-flight, corrupting the result and causing intermittent "No cabal file found" errors. Add an unpackLock (using the existing Lock/criticalSection from JobControl) to serialise the doesDirectoryExist check and tarball extraction in withTarballLocalDirectory. This is the same pattern already used for registerLock and cacheLock.
CompilerFlavor no longer has a GHCJS constructor and Distribution.Simple.GHCJS module no longer exists in stable-haskell/cabal. These imports + pattern were left behind from incomplete GHCJS removal. Removing them lets cabal-install bootstrap with GHC 9.8.4. Local fix for stable-haskell/ghc#wasm-cross-ghcup. Should be upstreamed to stable-haskell/cabal#stable-haskell/master.
binDirectoryFor was renamed/refactored to binDirectories (in ProjectPlanning.hs) with a different signature. The call site at ProjectOrchestration.hs:544 wasn't updated. Use elabBinDir directly — same value that binDirectories ultimately returns (see ProjectPlanning/Types.hs:496-497, 503).
6 tasks
angerman
added a commit
to stable-haskell/ghc
that referenced
this pull request
May 26, 2026
stable-haskell/cabal#359 (R8 patches) and #181 (Phase 0-2 branch) are open. Phase 3 ghcup-compatible bindist achieved locally — tar czhf + mk/wasm-relocate.sh. Verified self-contained tarball extracts and works from a fresh prefix.
angerman
added a commit
to stable-haskell/ghc
that referenced
this pull request
May 27, 2026
Records the Phase 5 deliverable + the cabal source patch (saved at lode/r12-cabal-target-prefix-aware-tool-guess.patch, 71 lines) needed to make the dual-compiler cabal build flow work on the ghcup-installed wasm bindist. The patch teaches `Cabal/src/Distribution/Simple/GHC.hs:: guessToolFromGhcPath` to detect target prefixes on the ghc binary (e.g. `wasm32-unknown-wasi-`) and try `<prefix>ghc-pkg` first when guessing the companion ghc-pkg. Without it, cabal falls back to PATH and grabs the BUILD compiler's ghc-pkg, triggering "Version mismatch between ghc and ghc-pkg" at dual-compiler configure time. The patched cabal-install binary at the cabal-3.17.0.0.stable.0 release tag has this fix baked in. The patch file is staged for upstreaming to stable-haskell/cabal#359. Verified end-to-end: - ghcup install ghc wasm32-wasi-9.14.0.stable.0 - ghcup install cabal 3.17.0.0.stable.0 - cabal build test-app → 1.7MB valid WebAssembly MVP wasm Final cabal bindist SHA256: 7f755b0810f5167b7f776470b5219834cdcbdad562998fd3c074b091be77e4d6 Resolves the original Task #13 (cabal symlink resolution) via the same patch — target-prefix is the ghcup end-user manifestation of the same `guessToolFromGhcPath` gap.
2 tasks
andreabedini
force-pushed
the
stable-haskell/master
branch
from
f840b28 to
22c22dc
Compare
andreabedini
force-pushed
the
stable-haskell/master
branch
from
843fceb to
01d053a
Compare
7 tasks
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
Two small fixes that let
cabal-installself-bootstrap against the boot-bundledCabal-3.10.3.0(i.e. with GHC 9.8.4). Both are clean-ups of references that were left behind by earlier refactors and are no longer reachable in any meaningful sense — the imports/types they point at don't exist in the currentCabal/Cabal-syntax.Patch 1/2 —
cabal-install/src/Distribution/Client/ProjectPlanning.hs:224:Patch 2/2 — `cabal-install/src/Distribution/Client/ProjectOrchestration.hs:544`:
Both files compile fine with these changes, and `cabal build cabal-install:exe:cabal` produces a working `cabal-install-3.17.0.1` binary against bootstrap GHC 9.8.4 + `Cabal-3.10.3.0`.
Why this matters
`stable-haskell/ghc` `stable-ghc-9.14` daily release CI has been failing every day since 2026-05-17 (~10 consecutive failures). The last successful build was 2026-04-23 at SHA `d8f0caefe58`. The trigger was the chore commit `e148c1c059` on the GHC project ("use stable-haskell/master for Cabal branch") — until that, `cabal.project.stage0` pinned the cabal source-repo to an explicit older SHA (`44817477ff6d…`) that didn't yet have the dead GHCJS/binDirectoryFor references. After the rename, builds picked up branch-tip drift and hit these two errors.
The CI cache mechanism masked this for a while (cached cabal binary kept being reused) but the chore commit invalidated the cache key (`hashFiles('cabal.project.stage0')`), forcing a from-scratch `make stable-cabal` rebuild that has been failing daily.
These two patches restore the ability to bootstrap `stable-haskell/cabal` against `stable-haskell/master` HEAD from a clean cabal-cache state.
Test plan