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 <ezy...@mit.edu> wrote: > 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 >
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
