Try target-prefixed ghc-pkg first in guessToolFromGhcPath#361
Open
angerman wants to merge 124 commits into
Open
Try target-prefixed ghc-pkg first in guessToolFromGhcPath#361angerman wants to merge 124 commits into
angerman wants to merge 124 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).
For cross-compiler bindists where the ghc binary is target-prefixed
(e.g. `wasm32-unknown-wasi-ghc`, `javascript-unknown-ghcjs`), the
companion tool typically uses the same prefix
(`wasm32-unknown-wasi-ghc-pkg`). The existing logic only tries the
bare tool name (`ghc-pkg`), falls back to PATH when not found, and
ends up picking the BUILD compiler's ghc-pkg from PATH — leading to
"Version mismatch between ghc and ghc-pkg" at configure time.
Detect the target prefix on the ghc binary (strip the
`ghc<versionSuffix>` tail from `takeBaseName p`) and prepend it to
the toolname as the first guess. Falls back to existing logic when no
prefix is detected (i.e. for bare `ghc` binaries).
Concrete example:
given_path = "/opt/ghc-wasm/bin/wasm32-unknown-wasi-ghc"
given_suf = "" (no -X.Y.Z version suffix)
given_prefix = Just "wasm32-unknown-wasi-"
guesses = [ "/opt/ghc-wasm/bin/wasm32-unknown-wasi-ghc-pkg" <-- new
, "/opt/ghc-wasm/bin/ghc-pkg"
]
Uses `isSuffixOf` + `take` instead of `Data.List.stripSuffix` for
base-4.19 compatibility (stripSuffix only entered Data.List in
base-4.20).
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
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.
Problem
For cross-compiler bindists where the ghc binary is target-prefixed
(e.g.
wasm32-unknown-wasi-ghc,javascript-unknown-ghcjs), thecompanion tool typically uses the same prefix
(
wasm32-unknown-wasi-ghc-pkg). The existingguessToolFromGhcPathlogic only tries the bare tool name(
ghc-pkg), falls back to PATH when not found, and ends up pickingthe BUILD compiler's
ghc-pkgfrom PATH — leading to"Version mismatch between ghc and ghc-pkg" at dual-compiler
configure time.
This was hit immediately when wiring up the stable-haskell wasm
cross-compiler in a Stage/Toolchain dual-compiler
cabal build:Fix
Detect the target prefix on the ghc binary (strip the
ghc<versionSuffix>tail fromtakeBaseName p) and prepend it tothe toolname as the first guess. Falls back to existing logic when no
prefix is detected (i.e. for bare
ghcbinaries).Concrete example:
Uses
isSuffixOf+takeinstead ofData.List.stripSuffixforbase-4.19 compatibility (
stripSuffixonly entered Data.List inbase-4.20).
Test plan
cross-compile project where with-compiler points at
`wasm32-unknown-wasi-ghc` — produces a valid WebAssembly MVP
wasm binary (1.7 MB). Without this patch, the same project
fails at configure with "Version mismatch between ghc and
ghc-pkg".
Related
binDirectoryFor patches in this branch (this one builds on those)