Procedure for updating GHC submodule pointer to Cabal

[Johan Tibell]

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 <ezyang at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20140703/223a7d69/attachment.html>