-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't be used to bootstrap GHC #13
Comments
There's a fourth option here as well:
Indeed, I added a cc @phadej |
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. |
While I'm sympathetic to the desire to have This is why I strongly encourage people to use |
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.
|
Option (5) also sounds reasonable. Is there a way to remove the custom |
@ndmitchell, #14 features a version of |
|
I've released |
In the most recent version of Shake, I added
heaps
as a dependency. Unfortunately, whileheaps
has no problematic actual dependencies, theSetup.hs
file depends onCabal
andcabal-doctest
. The latestcabal-doctest
is no longer compatible withCabal
HEAD as used to build GHC. There are a few ways around this issue:cabal-doctest
as a setup dependency.cabal-doctest
to work with HEAD Cabal, but that's will need to be done going forward too.CC @snowleopard
The text was updated successfully, but these errors were encountered: