-
Notifications
You must be signed in to change notification settings - Fork 696
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
Remove show-build-info command and generate build-info as a side-effect of 'build' #7498
Conversation
9567d55
to
7744fe4
Compare
535591f
to
500d0bd
Compare
3c7272f
to
f9844d6
Compare
@@ -67,6 +67,10 @@ srcPref distPref = distPref </> "src" | |||
hscolourPref :: HaddockTarget -> FilePath -> PackageDescription -> FilePath | |||
hscolourPref = haddockPref | |||
|
|||
-- | 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
@@ -556,6 +564,17 @@ configureOptions showOrParseArgs = | |||
"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
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 ;)
@@ -67,6 +67,10 @@ srcPref distPref = distPref </> "src" | |||
hscolourPref :: HaddockTarget -> FilePath -> PackageDescription -> FilePath | |||
hscolourPref = haddockPref | |||
|
|||
-- | 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?
@@ -2,7 +2,7 @@ | |||
-- This module defines a simple JSON-based format for exporting basic | |||
-- 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?
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.
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-info
to configure ofSetup.hs
and generate build-info.json right next tosetup-config
.Readable by tooling.
build-type: Simple
build-type: Custom
cabal configure --enable-dump-buildinfo
(e.g. enable/disable the generation)buildInfoJson
toplan.json
output