adding new testsets to the directory, does not trigger a rebuild/generation.

[Eh2406]

You already know about the issue. You describe it in the readme. I open this issue to track possible solutions, and to make you aware of the discussion in internals.

[frehberg]

Thanks for the link to the Pre-RFC :) good to know

[frehberg]

Extend the example, demonstrating usage of build-script-feature cargo:rerun-if-changed=PATH
https://crates.io/crates/build-helper
https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script

The conditional build process might look like:

1. The build-script build.rs will just glob/iterate the specific files of the test-data directory, printing to console the message rerun-if-changed=PATH for each one
2. The parent process cargo will evaluate the console-output of build.rs and if the file-set differs compared to the previous file-set (?) or the timestamps of those files did change, then the crate will be re-built and the test-generator will run again.

Note: I am not sure cargo is storing the file-set for later comparison with the next file-set
(directories are not supported, just regular files)

Comments are welcome!

[Eh2406]

I believe cargo is storing the file-set, I can find a citation if you would like. I don't know if Cargo will rerun the build script if a file is added. It won't be in the list of rerun-if-changed.
build.rs does have the disadvantage of running even when building the library not for tests.
All so cc this blog post for a build.rs based system.

[frehberg]

yes, build.rs is run every time, but as long as the data-sets are not changing, the cargo logic should then not rebuild the lib/app.The point is that build.rs will not generate rs-files, but just iterating the data-set files.

[frehberg]

Added a description to reddit https://www.reddit.com/r/rust/comments/aig2iv/cargo_reliable_code_generation_declaring/

[frehberg]

Hast Du die Technik mit dem build-script bzw build-deps schon ausprobiert? Kann ich das Ticket schließen?

[Eh2406]

Thanks for the workaround, and the explanation. I have not had time to experiment. I will close until someone can demonstrate a real occurrence.