RFC: use cargo's depfiles

[russelltg]

This is not complete yet, but wanted to gauge interest before polishing up.

An annoying thing about corrosion is that it doesn't use ninja's dependency tracking at all, instead depending on cargo's. This means that cargo has to be invoked for every call of ninja, regardless of if anything needs to be done or not.

Cargo outputs depfiles that are exactly for this purpose, so this PR hooks that up. This lets ninja do nothing when there is no work to do, but otherwise do work.

This required temporarily disabling the hostbuild & profile features, as those are 'target' generator features which are not allowed in this context.

Do you think it would be acceptable to replace the generator expressions with a DEFER call like is done for the byproducts?

[russelltg]

See also #624 and #206

[jschwe]

Cargo outputs depfiles that are exactly for this purpose, so this PR hooks that up.

I think it would cause rebuilds to also be skipped if environment variables change (that would normally cause cargo to rebuild).
Those environment variables are listed in the depfile, but as comments. We would need to test what happens if user cmake code sets an environment variable (e.g. controlled by some CMake variable). Would the target be rebuilt as expected if we reconfigure the CMake project, and the CMake code sets the environment variable to a different value? Or would ninja just look at the depfile, and decide that since no files changed, no rebuild is necessary? One might be able to work around that by adding a rule which processes the depfile and makes a file with hashes of all the used environment variable, and make the rust target rebuild if that file changed.

Do you think it would be acceptable to replace the generator expressions with a DEFER call like is done for the byproducts?

That sounds quite complex to me tbh. I'm not sure if it feasible here. For hostbuild I think we could remove the generator expression, and require that hostbuild is passed only via corrosion_import_crate. I think there is typically only one / very few hostbuild programs in a project, so this shouldn't cause much code churn / added verbosity.

For the profile I'm less sure what an alternative could be. Perhaps we could use switch to a global genex instead, that maps cmake build types to rust profiles (e.g. <CONFIG:Debug:dev>), which could be overriden by the user.
CMake doesn't offer to change the build config per target, so perhaps the cargo profile should have never been per target in the first place.