Can't be used to bootstrap GHC

Question

Can't be used to bootstrap GHC

Closed this issue 6 years ago · 8 comments

In the most recent version of Shake, I added heaps as a dependency. Unfortunately, while heaps has no problematic actual dependencies, the Setup.hs file depends on Cabal and cabal-doctest. The latest cabal-doctest is no longer compatible with Cabal HEAD as used to build GHC. There are a few ways around this issue:

Stop using cabal-doctest as a setup dependency.
Have me inline the parts of Heap I need into Shake itself. I'm going to do that as a temporary step anyway.
Upgrade cabal-doctest to work with HEAD Cabal, but that's will need to be done going forward too.

CC @snowleopard

Answer 1 · 2019-02-05T10:51:20.000Z

There's a fourth option here as well:

Use head.hackage to build dependencies with GHC HEAD.

Indeed, I added a head.hackage patch for cabal-doctest here for precisely this reason.

cc @phadej

Answer 2 · 2019-02-05T10:59:32.000Z

I don't use head.hackage, so it doesn't fit my workflow, so while it might be enough for some people I'd still need another solution.

Answer 3 · 2019-02-05T11:04:40.000Z

While I'm sympathetic to the desire to have shake build with GHC HEAD at all times, keeping cabal-doctest in sync with HEAD can prove to be a nightmare due to how quickly the Cabal API changes in its development process. We'd have to constantly be churning out new Hackage releases of cabal-doctest to stay in line with the moving target of HEAD. More than likely, most of those releases would bitrot by the time the next major release of GHC came out, which would require time and effort to go back and make metadata revisions to repair the old, broken versions of cabal-doctest that no longer compile with the new major release.

This is why I strongly encourage people to use head.hackage, since it allows people who use GHC HEAD to stay on top of the latest development changes without spamming Hackage with a bunch of releases to stay in sync with HEAD. It also means that developers don't have to worry about incurring dependencies as much as they used to, since head.hackage can ensure that they're always building without issues.

Answer 4 · 2019-02-05T11:12:41.000Z

5th option: remove build-type: Custom. It's either means ripping of doctests or make working `cabal doctest` (which might be GSOC project this year). For `shake`, I'd stay out of using `build-type: Custom` packages. They are difficult in bootstrapping-like situations. Also packages depending on `template-haskell`, and ...

…

Sent from my iPhone

On 5 Feb 2019, at 13.04, Ryan Scott ***@***.***> wrote: While I'm sympathetic to the desire to have shake build with GHC HEAD at all times, keeping cabal-doctest in sync with HEAD can prove to be a nightmare due to how quickly the Cabal API changes in its development process. We'd have to constantly be churning out new Hackage releases of cabal-doctest to stay in line with the moving target of HEAD. More than likely, most of those releases would bitrot by the time the next major release of GHC came out, which would require time and effort to go back and make metadata revisions to repair the old, broken versions of cabal-doctest that no longer compile with the new major release. This is why I strongly encourage people to use head.hackage, since it allows people who use GHC HEAD to stay on top of the latest development changes without spamming Hackage with a bunch of releases to stay in sync with HEAD. It also means that developers don't have to worry about incurring dependencies as much as they used to, since head.hackage can ensure that they're always building without issues. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Answer 5 · 2019-02-05T11:16:11.000Z

Option (5) also sounds reasonable. Is there a way to remove the custom Setup.hs stanza while still retaining the ability to run doctests locally (within the heaps repo itself)?

Answer 6 · 2019-02-05T13:39:44.000Z

@ndmitchell, #14 features a version of heaps without the cabal-doctest dependency. Would this work for your needs?

Answer 7 · 2019-02-05T15:45:27.000Z

would be the best option, and #14 gets there. I think @phadej is right that Shake should avoid build-type Custom.

Answer 8 · 2019-02-05T18:40:10.000Z

I've released heaps-0.3.6.1 to Hackage without a cabal-doctest dependency. Let me know if anything else is required on heaps' end.