danielschemmel
commented
1 year ago This issue is quite a bit more annoying than it seems at first glance, and explicitly rerunning when any *.rs file changes is the most robust solution I have found so far.
First of, rerunning the build script on any change is necessary, as the output may change. For example, modifying any file under source control will make your repository dirty, which means that the build script has to be rerun to provide the changed info, which then requires anything using that info to be rebuilt, so that finally your binary introduces itself as 0123456.dirty or however you may wish to represent that info. I assume this is part of what you are experiencing - maybe not a great result, but at least somewhat intentional.
Second, we do not completely own the build script, meaning that other rerun-if-changed lines might be emitted by different code (e.g., you could be running a parser generator). If that happens, the build script is only rerun for anything that triggers one of the rerun-if-changed lines.
I would love a better / more customizable solution for globbing, but the default behavior should be correct and as complete as possible.
The globbing in
rebuild_if_project_changesgoes over all .rs files in any subdirectory, including tests/ which are separate crates.In my case, this causes a recompile of the entire project when a test file is changed, turning a 0.3s build into a 30s build.
My first thought was, we could improve this by making it ignore tests/ by default, or just scan src/.
My second thought was, isn't this what cargo does by default? What problem is build-info trying to solve by adding a rerun-if-changed to every file?