Skip to content
Snippets Groups Projects
Forked from Glasgow Haskell Compiler / GHC
Loading
  • Matthew Craven's avatar
    dbe27152
    Repair the 'build-cabal' hadrian target · dbe27152
    Matthew Craven authored and Cheng Shao's avatar Cheng Shao committed
    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.
    dbe27152
    History
    Repair the 'build-cabal' hadrian target
    Matthew Craven authored and Cheng Shao's avatar Cheng Shao committed
    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