Update Cabal submodule to HEAD (1.21)
Edward Z. Yang
ezyang at mit.edu
Sun Jul 20 16:08:42 UTC 2014
As long as we get Cabal to do a release before we cut a release,
it should be fine, so all we need is for Cabal to take the patch.
Edward
Excerpts from Joachim Breitner's message of 2014-07-20 16:55:20 +0100:
> Hi,
>
> Am Sonntag, den 20.07.2014, 16:58 +0200 schrieb Joachim Breitner:
> > > > I suppose if you /really/ wanted to we could add a
> > > > macro to disable ctl-c support and pass it on the zeroboot.
> > >
> > I tried that (there is already a macro BOOTSTRAPPING), and then it does
> > build inplace/bin/ghc-cabal.
> >
> > But the next thing it tries to do is to build Cabal, which then fails,
> > expecting the newer process.
> >
> > So process needs to be added to PACKAGES_STAGE0. But this adds
> > "--constriant process == 1.2.0.0" to the options when building hsc2hs,
> > which then fails – but only with make -j2. In a sequential build,
> > process happens to be built before hsc2hs....
> >
> > So I guess I need to tell make somehow to first configure and register
> > process and then configure and register hsc2hs. But I’m lost in GHC’s
> > makefiles... Can anyone point me into the right direction?
>
> So I got a working configuration. The following patch needs to be
> applied to Cabal:
>
> diff --git a/Cabal/Distribution/Simple/Utils.hs b/Cabal/Distribution/Simple/Utils.hs
> index 9096186..54df19d 100644
> --- a/Cabal/Distribution/Simple/Utils.hs
> +++ b/Cabal/Distribution/Simple/Utils.hs
> @@ -379,7 +379,12 @@ rawSystemExitWithEnv verbosity path args env = do
> hFlush stdout
> (_,_,_,ph) <- createProcess $
> (Process.proc path args) { Process.env = (Just env)
> - , Process.delegate_ctlc = True }
> +#ifndef BOOTSTRAPPING
> +-- delegate_ctlc has been added in process 1.2, and we still want to be able to build
> +-- bootstrap GHC on systems not having that version
> + , Process.delegate_ctlc = True
> +#endif
> + }
> exitcode <- waitForProcess ph
> unless (exitcode == ExitSuccess) $ do
> debug verbosity $ path ++ " returned " ++ show exitcode
> @@ -405,7 +410,12 @@ rawSystemIOWithEnv verbosity path args mcwd menv inp out err = do
> , Process.std_in = mbToStd inp
> , Process.std_out = mbToStd out
> , Process.std_err = mbToStd err
> - , Process.delegate_ctlc = True }
> +#ifndef BOOTSTRAPPING
> +-- delegate_ctlc has been added in process 1.2, and we still want to be able to build
> +-- bootstrap GHC on systems not having that version
> + , Process.delegate_ctlc = True
> +#endif
> + }
> exitcode <- waitForProcess ph
> unless (exitcode == ExitSuccess) $ do
> debug verbosity $ path ++ " returned " ++ show exitcode
>
> and this adjustment made to GHCs build system:
>
> diff --git a/ghc.mk b/ghc.mk
> index e9d7e83..cfe46ec 100644
> --- a/ghc.mk
> +++ b/ghc.mk
> @@ -382,8 +382,10 @@ else
> # Packages that are built by stage0. These packages are dependencies of
> # programs such as GHC and ghc-pkg, that we do not assume the stage0
> # compiler already has installed (or up-to-date enough).
> +# "process" can be removed once the version required by Cabal is not
> +# particularly new any more.
>
> -PACKAGES_STAGE0 = Cabal/Cabal hpc bin-package-db hoopl transformers
> +PACKAGES_STAGE0 = process Cabal/Cabal hpc bin-package-db hoopl transformers
> ifeq "$(Windows_Host)" "NO"
> ifneq "$(HostOS_CPP)" "ios"
> PACKAGES_STAGE0 += terminfo
> @@ -732,6 +734,11 @@ fixed_pkg_prev=
> $(foreach pkg,$(PACKAGES_STAGE0),$(eval $(call fixed_pkg_dep,$(pkg),dist-boot)))
> utils/ghc-pkg/dist/package-data.mk: $(fixed_pkg_prev)
> compiler/stage1/package-data.mk: $(fixed_pkg_prev)
> +
> +# we also need to configure hsc2hs after process has been configured, as
> +# BOOT_PKG_CONSTRAINTS will make hsc2hs want to use the in-tree process library.
> +utils/hsc2hs/dist/package-data.mk : libraries/process/dist-boot/package-data.mk
> +
> endif
>
> ifneq "$(BINDIST)" "YES"
>
>
>
> Now I’d like to apply this change, but I’m not sure how to proceed with
> such GHC-specific fixes to Cabal. I guess I could create a pull request,
> wait for the Cabal devs to apply it, wait for the next Cabal release,
> and then update the submodule. Is there anything quicker that gets the
> fix in until that has happened?
>
> Greetings,
> Joachim
>
More information about the ghc-devs
mailing list