Procedure for updating GHC submodule pointer to Cabal
Hello all, I am working on module reexports (https://ghc.haskell.org/trac/ghc/ticket/8407) and this functionality requires concurrent changes to GHC and Cabal. However, GHC is currently tracking 1.20, but Cabal HEAD has marched on. My question is, if I am to do this development on HEAD, what is the standard operating procedure for retargeting GHC to a recent version of Cabal? Of course I have to go and validate the build, but are there any other considerations? Is this recorded anywhere? Thanks, Edward
With my Cabal maintainer hat on there are two important considerations:
* Make sure your patches make it upstream.
* Make sure that we make a Cabal release with your changes in it before
the next GHC release you're targeting your feature for.
In the past we had problems with GHC HQ releasing packages at HEAD without
upstream's blessing and sometimes with extra patches that never made it
upstream (which leaves a big risk that these patches get lost next time
upstream makes a release).
You can sync GHC's submodule to the latest Cabal HEAD and test to make sure
your patches work there. Alternatively GHC HQ can have a local Git branch
of 1.20 with your extra patches (but then really make sure that the above
holds.)
On Thu, Jul 3, 2014 at 3:45 PM, Edward Z. Yang
Hello all,
I am working on module reexports ( https://ghc.haskell.org/trac/ghc/ticket/8407) and this functionality requires concurrent changes to GHC and Cabal. However, GHC is currently tracking 1.20, but Cabal HEAD has marched on.
My question is, if I am to do this development on HEAD, what is the standard operating procedure for retargeting GHC to a recent version of Cabal? Of course I have to go and validate the build, but are there any other considerations? Is this recorded anywhere?
Thanks, Edward _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Hi, On 2014-07-03 at 15:57:00 +0200, Johan Tibell wrote:
With my Cabal maintainer hat on there are two important considerations:
* Make sure your patches make it upstream. * Make sure that we make a Cabal release with your changes in it before the next GHC release you're targeting your feature for.
In the past we had problems with GHC HQ releasing packages at HEAD without upstream's blessing and sometimes with extra patches that never made it upstream (which leaves a big risk that these patches get lost next time upstream makes a release).
You can sync GHC's submodule to the latest Cabal HEAD and test to make sure your patches work there. Alternatively GHC HQ can have a local Git branch of 1.20 with your extra patches (but then really make sure that the above holds.)
(Note: In the following, you can optionally replace 'master' by HEAD while reading) Fyi, right now, github.com/haskell/Cabal is automatically mirrored to git.haskell.org/packages/Cabal, which for example means that pushing to git.haskell.org's Cabal.git 'master' branch is disallowed via configuration. This setup was made possible by having Cabal.git as a submodule, so that this provides implicitly a lagged mirror repository, while avoiding the risk to ever diverge from the upstream Cabal repo (as you've mentioned happened in the past). ideally (IMHO), the changes needed for #8407 should be submitted to and accepted by Cabal upstream first (as they need to be backward compat with older GHCs anyway, so there's should be no reason not to get them into Cabal 'master') and after they got merged into Cabal 'master', ghc.git 'master's submodule can be updated to Cabal 'master' -- and from that point on, GHC 7.10 will no longer be based on Cabal 1.20 but rather be doomed to depend on a future Cabal 1.22+ release... probably.
participants (3)
-
Edward Z. Yang -
Herbert Valerio Riedel -
Johan Tibell