Forked from
Glasgow Haskell Compiler / GHC
-
Fixes #23117. Fixes #23281. Fixes #23490. This required: * Updating the bit-rotted compiler/Setup.hs and its setup-depends * Listing a few recently-added libraries and utilities in cabal.project-reinstall * Setting allow-boot-library-installs to 'True' since Cabal now considers the 'ghc' package itself a boot library for the purposes of this flag Additionally, the allow-newer block in cabal.project-reinstall was removed. This block was probably added because when the libraries/Cabal submodule is too new relative to the cabal-install executable, solving the setup-depends for any package with a custom setup requires building an old Cabal (from Hackage) against the in-tree version of base, and this can fail un-necessarily due to tight version bounds on base. However, the blind allow-newer can also cause the solver to go berserk and choose a stupid build plan that has no business succeeding, and the failures when this happens are dreadfully confusing. (See #23281 and #24363.) Why does setup-depends solving insist on an old version of Cabal? See: https://github.com/haskell/cabal/blob/0a0b33983b0f022b9697f7df3a69358ee9061a89/cabal-install/src/Distribution/Client/ProjectPlanning.hs#L1393-L1410 The right solution here is probably to use the in-tree cabal-install from libraries/Cabal/cabal-install with the build-cabal target rather than whatever the environment happens to provide. But this is left for future work.
Fixes #23117. Fixes #23281. Fixes #23490. This required: * Updating the bit-rotted compiler/Setup.hs and its setup-depends * Listing a few recently-added libraries and utilities in cabal.project-reinstall * Setting allow-boot-library-installs to 'True' since Cabal now considers the 'ghc' package itself a boot library for the purposes of this flag Additionally, the allow-newer block in cabal.project-reinstall was removed. This block was probably added because when the libraries/Cabal submodule is too new relative to the cabal-install executable, solving the setup-depends for any package with a custom setup requires building an old Cabal (from Hackage) against the in-tree version of base, and this can fail un-necessarily due to tight version bounds on base. However, the blind allow-newer can also cause the solver to go berserk and choose a stupid build plan that has no business succeeding, and the failures when this happens are dreadfully confusing. (See #23281 and #24363.) Why does setup-depends solving insist on an old version of Cabal? See: https://github.com/haskell/cabal/blob/0a0b33983b0f022b9697f7df3a69358ee9061a89/cabal-install/src/Distribution/Client/ProjectPlanning.hs#L1393-L1410 The right solution here is probably to use the in-tree cabal-install from libraries/Cabal/cabal-install with the build-cabal target rather than whatever the environment happens to provide. But this is left for future work.
Code owners