-
Notifications
You must be signed in to change notification settings - Fork 706
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
Reinstate 'initialBuildSteps' function (backport #9950) #9961
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
synopsis: Re-instate `initialBuildSteps` | ||
packages: Cabal | ||
issues: #9856 | ||
prs: #9950 | ||
|
||
description: { | ||
|
||
The `initialBuildSteps` function from `Distribution.Simple.Build`, which had | ||
been hastily removed, has been reinstated. | ||
|
||
It now comes with a deprecation warning: calling that function does not suffice | ||
to prepare the sources for a package, as there are other steps that one might | ||
also need to perform: | ||
|
||
- running pre-processors (such as alex/happy) | ||
- running pre-build hooks or custom logic | ||
(in build-type: Hooks or build-type: Custom or Configure) | ||
|
||
Consumers wanting to prepare the sources of a package, e.g. in order to launch a | ||
REPL session, are advised to run `setup repl --repl-multi-file=<fn>` instead. | ||
} |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My only thought - and it is not a 'blocker' - is that
Setup repl --repl-multi-file=<fn>
could have greater consistency with the Cabal User Guide, which is written in terms of:If that is applicable, it is also applicable below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me try to understand:
Setup
assumes the setup script is compiled (with something likeghc --make Setup.hs
, I guess?) and the binary is invoked, whilerunhaskell Setup.hs
interprets it and thus runs is? Is that it? Do both of these forms work so that it's just a user choice? If so, I'd rather avoid creating a new PR on master to change that (the original PR is already merged), unless @mpilgrem feels strongly one of the forms is misleading or bad style. But if one of these is actually wrong, please let me know and I will create the PR myself (and let's also fix here in that case).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My review comment was a subtle one, and I do not feel strongly about it. I was exploring the following:
What does it mean to advise:
run @Setup repl --repl-multi-file=<fn>@
?It means (as documented in the Cabal User Guide for other uses of the Cabal Haskell 'script' file named (by convention)
Setup.hs
) to commandrunhaskell Setup.hs --repl-multi-file=<fn>
(or, equivalently,runghc Setup.hs --repl-multi-file=<fn>
). My suggestion was to state things more plainly in the Haddock documentation and in a way consistent with the User Guide.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get it now, thank you. Yes, consistency is good. I'm glad that's the only problem you see in this PR, so I suggest we merge it and remember to keep docs consistent in the future (e.g., if the comment on master branch survives longer than the deprecated feature and so we'd be editing it again in the future).