On Mon, Mar 29, 2021 at 00:36:51 -0700, Marc Delorme wrote:
> In my project, I have a tool generating reflection data by parsing C++
> headers. This tool read a set of C++ headers, find classes to be reflected,
> generates one header file per reflected classes (implicit outputs) and
> generate one .cpp containing reflection data implementation (explicit
> I would like ninja to re-generate the header file is they are missing. It
> is possible to do it using the *dyndep* feature, but it requires to split
> my code generation in two steps. Unfortunately discovering those implicit
> outputs require to parse all the C++, from that point it is a pity not to
> generate code at the same time but reparse everything in another step to
> generate code.
Dyndep needs to be separate because it is about finding what is *needed*
for another step to run first.
> I wish I could register implicit outputs in depfile, but I did not find in
> depfile syntax to do that and by reading ninja source code it does not seem
There would need to be a new syntax in the depfile for this. Probably
guarded by an `dynout = 1` flag or the like. Alternatively, it could
just be a `dynout = list.txt` possibly with a `dynprefix =
path/to/prefix/to/each/entry` (to allow for `tar xf` / `tar tf`
FWIW, this could also be used to rerun rules when files are deleted from
"batched" operations (e.g., extracting a tarball) by tracking the
extracted files via `dynout`.