Output cargo:rerun-if-changed

[segevfiner]

In order for cargo to correctly rebuild when the manifest or resources change, you need to output cargo:rerun-if-changed. This needs to be output for both the resource script and the resources it embeds. Getting the list of resources might be a bit more tricky as it requires cooperation from the resource compiler similar to how you can request Makefile dependencies from gcc or parse cl output for includes.

[nabijaczleweli]

Well, getting the dependencies is impossible, but cargo rebuilds if I change the .rc, too, despite the lack of rerun-if-changed, which I didn't expect and is a good point, so hm.

[segevfiner]

"Hmm" indeed. Perhaps it implicitly adds a dependency from some other emitted property.

[LPGhatguy]

If a build script doesn't not output ANY rerun-if-changed directives, the build script will be rerun if any file in the project changes. That is to say, using embed-resource without any other build script functionality will work, but it will stop functioning if new code is added that uses this feature.

Importantly, emitting no rerun-if-changed directives will cause Cargo to scan the entire project file for changes. In my project, that made Cargo access several gigabytes of asset files needed at runtime but unrelated to the build. This was bad for our build times.

I worked around this by manually emitting our own rerun-if-changed lines:

println!("cargo:rerun-if-changed=build/windows/manifest.rc");
println!("cargo:rerun-if-changed=build/windows/cyrtanthus.manifest");
embed_resource::compile("build/windows/manifest.rc");

[nabijaczleweli]

That explains it, but unfortunately there's still the issue that the default behaviour is better in the general case than speccing just the .rc, since that starts with an unspecified pre-processing step with no possibility to spec an equivalent of cc -MD – it either runs over-zealously or not enough, and the latter is much worse. Unless you have a suggestion for extracting that dependency data, then the best I can do is put it in an erratum in the top-level doc, I think?

[LPGhatguy]

Unless you have a suggestion for extracting that dependency data, then the best I can do is put it in an erratum in the top-level doc, I think?

Yeah, sounds like the best bet. Having the user write things out isn't too bad and documenting this is a good idea.

[nabijaczleweli]

Erratum added for v1.8.0