-
Notifications
You must be signed in to change notification settings - Fork 724
Remove show-build-info command and generate build-info as a side-effect of 'build' #7498
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
Conversation
9567d55 to
7744fe4
Compare
535591f to
500d0bd
Compare
3c7272f to
f9844d6
Compare
|
|
||
| -- | Build info json file, generated in every build | ||
| buildInfoPref :: FilePath -> FilePath | ||
| buildInfoPref distPref = distPref </> "build-info.json" |
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.
Possible inconsistency, file name is build-info but other flags are buildinfo. Any preferences?
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.
As far as I'm concerned buildinfo is a word.
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.
While I also find "buildinfo" more natural I found some precedent on the cmdline: --enable-debug-info is a thing so maybe we should be consistent with that?
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 choose consistency with debug-info, everything will be renamed to build-info
4fc7f04 to
bda7743
Compare
| "Don't emit debug info" | ||
| ] | ||
|
|
||
| , multiOption "dump-buildinfo" |
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.
Why conditionally? Is there a reason not to write it always?
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 did not want to change the default behaviour, but it would be indeed better if it was always generated. Subject to bikeshed.
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.
performance is not a problem I suppose
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 woudn't be so sure that performance couldn't be a problem, best to err on the side of caution when people with pitchforks are sure to follow if build speed regresses ;)
If it turns out to be unproblematic it's an easy default to change: just ignore the flag going forward, but the other way around isn't so easy since tooling would break if we introduce a flag.
Lastly my understanding is that hie-bios currently always does at least one (implicit) build call anyway though the repl command so we're just maintaining the status quo if it has to do one with a special flag to get the buildinfo.
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.
Lastly my understanding is that hie-bios currently always does at least one (implicit) build call anyway though the repl command so we're just maintaining the status quo if it has to do one with a special flag to get the buildinfo.
yeah but it would be nice if we get to make no one if possible, though
DanielG
left a comment
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.
This is looking pretty good. I'm super excited that we figured out how to roll this into build rather than introducing a new command.
Apart from nits and bikeshedding the only real points that need addressing are the non-nullability of the compiler "path", the nullability of "build-info" in plan.json or an alternate mechanism for downstreams to detect if the "lib:Cabal too old" case is happening and as always moar docs ;)
|
|
||
| -- | Build info json file, generated in every build | ||
| buildInfoPref :: FilePath -> FilePath | ||
| buildInfoPref distPref = distPref </> "build-info.json" |
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.
While I also find "buildinfo" more natural I found some precedent on the cmdline: --enable-debug-info is a thing so maybe we should be consistent with that?
| -- information about a Cabal package and the compiler configuration Cabal | ||
| -- would use to build it. This can be produced with the | ||
| -- @cabal new-show-build-info@ command. | ||
| -- @cabal build --enable-dump-buildinfo@ command. |
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.
Seeing that one would pass the (configure) enable flag to build like this makes me wonder if --dump-buildinfo should imply --enable-buildinfo on the build cmdline? cabal build --enable-buildinfo --dump-buildinfo=PATH seems quite redundant.
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.
no flag --dump-buildinfo exists yet, I would leave that to a follow-up PR, unless someone objects
| flags_3_5_0 = flags_latest { | ||
| -- Cabal < 3.5 does not understand --dump-build-info | ||
| configDumpBuildInfo = NoFlag | ||
| } |
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 think we ought to emit a warning about this somewhere.
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.
Sure but where?
DanielG
left a comment
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.
Just another per-commit review pass. Something seems off about the commit messages not being in sync with the diffs.
53de4fb to
38f189f
Compare
e03c434 to
7a9f973
Compare
doc/cabal-project.rst
Outdated
| on how to build an individual component, such as compiler version, modules of a component and | ||
| how to compile the component. | ||
|
|
||
| The output format is in json, and the exact location can be discovered from ``plan.json``. |
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.
This still doesn't seem to mention what the field name in plan.json is or where that field can be found like I suggested above.
DanielG
left a comment
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.
We should add some comments to make sure code, json schema and docs stay in sync in the face of other people changing this code in the future.
Adds missing file information for test and benchmark stanzas.
Removes 'show-build-info' command from 'lib:Cabal' and replaces it by generating build-info whenever a build happens. Add flag '--dump-buildinfo' to signal the build step to dump build information for the package/component we are currently building.
c26077d to
9b56d10
Compare
Refactor the API slightly s.t. a ConfiguredProgram for the Compiler is passed to build-info generation directly.
9b56d10 to
0702193
Compare
|
are you scared of pressing the button? 😝 |
|
Well, someone else should press the merge button :) |
|
Alright then, been eyeing that button all day :D |
|
@fendor @DanielG Commit 024c060 of this PR broke |
|
Uhoh. We do need |
|
Indeed fendor seems to have forgotten to add the jsonschema extension to conf.py, but the users-guide target was already broken before the merge AFAICT :] According to my bisect 0f041b6 is to blame originally. |
|
See #7637. |
This is the first step for implementing Approach 3 of #7489.
Mainly extracted from #7478
In particular, add a flag
--enable-build-infoto configure ofSetup.hsand generate build-info.json right next tosetup-config.Readable by tooling.
build-type: Simplebuild-type: Customcabal configure --enable-dump-buildinfo(e.g. enable/disable the generation)buildInfoJsontoplan.jsonoutput