dkg
commented
1 year ago I'm a bit puzzled by this. the curl crate itself depends on curl-sys, so if curl-sys gets rebuilt, then curl will get rebuilt.
This change looks like it makes it so that the opposite is also true: if curl gets rebuilt, then curl-sys will also get rebuilt.
The result is that any project that depends (even indirectly) on curl will always rebuild both curl-sys and curl each time the user invokes cargo build. And, every crate on top of them as well will also get rebuilt each run of cargo build. This means that each source code change in such a project requires a rebuild of a whole tree of modules -- anything rooted in curl, which is pretty tedious. (i'm running into that right now)
When doing local development on Linux, if any of the curl source files are changed, cargo will not trigger a rebuild. This is because pkg_config prints various rerun-if-env-changed values which prevents scanning for source file changes. This adds a basic rerun-if-changed to pick up any changes to the curl submodule.
The only downside to this is if the package is being built before initializing the submodule, this code will initialize it, but with a timestamp after the build started. This means the second cargo command will rebuild again, unfortunately. I don't think there is any way to avoid this, and I think should be sufficiently rare not to matter. CI here initializes the submodule before starting.