Add support for -n "dry run" feature #12
Conversation
jamesr
force-pushed
the
dry_run
branch
2 times, most recently
from
248bccb to
17e31a2
Compare
|
I took a crack at fixing up the record_finished path and the inputs-that-are-generated-outputs check to match - PTAL. |
| ) -> anyhow::Result<TaskResult> { | ||
| if let Some(rspfile) = rspfile { | ||
| write_rspfile(rspfile)?; | ||
| } | ||
| if dry_run { |
There was a problem hiding this comment.
Hm, is it intentional here to write the rspfile in the dry run case? I am not sure about it, but my first impression is we shouldn't write any files, and perhaps even not start any tasks.
There was a problem hiding this comment.
Ninja does write rsp files in dry run mode. I know that some people use -n to generate rsp files.
Then again, n2 doesn't delete rsp files by default, so maybe that's less needed here.
It is weird if -n mode has visible side effects, and using it for writing rsp files feels like a bit of a hack.
There was a problem hiding this comment.
What's the use case for generating rsp files with -n? Debugging?
There was a problem hiding this comment.
My intent here was to match ninja - but upon reflection I agree that the ninja behavior is strange. Is the goal of n2 in general to match behaviors or to rethink them? I.e. do you anticipate having a keeprsp control as well?
I've never intentionally used the -n flag to examine rspfiles but I've certainly used and seen folks deeply confused by ninja's keeprsp behehavior. Perhaps there's a better way to approach that entirely.
There was a problem hiding this comment.
What's the use case for generating rsp files with -n? Debugging?
I don't use it for this myself, so I'm not 100% sure, but I think the answer is "yes". These are concrete examples:
- Being able to manually run commands. You might want to run with
-vto get a commandline, but if that uses a rsp file and it's not on disk and you forgot to pass-d keeprsp, you can re-run with-nto create the rsp file. - You just might want to read the rsp file to look at its contents.
|
@jamesr can you talk about your use case for this? Would help understand whether we want rspfiles or not, or what exactly should happen in general. E.g. if you had foo.c compiles to foo.o links to foo, one possible interpretation of a dry-run build is to say "I would start by compiling foo.o, and I can't go any farther than that because I don't have foo.o for the next step". |
|
The way that I've usually used "-n" is to ask the tool what steps it thinks it should run given the currently available information. In that use case I would consider the rspfile's contents as part of the tool's description of the step that it wants to run and would like access to that information. Another way to factor it would be to have the dry run simply go through the steps it would like to run and have a different query to ask for a fuller description of a particular step or set of steps, including rspfile file contents. |
This executes the normal build logic up until the point of spawning a subprocess at which point it pretends the command succeeded. Internal command such as generating directories and regeneration still happen. Missing input files are permitted in dry run mode.
evmar
force-pushed
the
main
branch
2 times, most recently
from
03de3da to
afe500f
Compare
evmar
force-pushed
the
main
branch
2 times, most recently
from
95e6f5f to
1b31c58
Compare
evmar
force-pushed
the
main
branch
2 times, most recently
from
8cafbda to
d43e8ca
Compare
|
I had kept this open for the use case notes, but they'd be better as a bug, |
This executes the normal build logic up until the point of spawning a
subprocess at which point it pretends the command succeeded. Internal
command such as generating directories and regeneration still happen.
Missing input files are permitted in dry run mode.