Forked from
Glasgow Haskell Compiler / GHC
Source project has a limited visibility.
-
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
Assign users and groups as approvers for specific file changes. Learn more.