So sounds like this is pure-input/output codegen that you are performing directly, and not something others will run. I would be interested to hear from others using warnings to see if there is something more we could learn.
by the way. have you considered snapshot testing for your codegen? The idea is that instead of using build.rs to generate content if changed, you move the generator to a test and commit the result. The test will fail if they diverge (to catch direct edits) and you can use an environment variable to "bless" the new generated output, overwriting whats committed instead of erroring.
When used in a library, this can be a big help to build times for dependents because the code generator and its dependencies are no longer built since callers don't care about dev-dependencies / tests.
For applications, this could likely still offer build speed improvements because the code generator is no longer in the critical path but is now being built with the tests, offering more parallelism, and being run in parallel to other tests.
The main trade off with this approach is if the code gen source has a high velocity of changes. In your case in particular, there really isn't a warning mechanism for tests or a good way to dynamically ignore tests and report a cause. I am working on both but that is unfortunately one of my lower priorities atm.
Examples of this approach:
- Cargo uses it for generating its documentation
- Cargo uses it for generating schema files
- Typos uses it for generating dictionary files