cmake/ninja targets from corrosion are always dirty

[milianw]

Using corrosion in a cmake project will never go into the nothing to do state, there are always dirty targets.

To reproduce, first build your project that is using corrosion:

$ ninja

Now the expectation is that you'd get:

$ ninja
ninja: no work to do.

Instead you get (the example output below is from a tiny project, image_filter is the crate we try to import via corrosion):

$ ninja -t explain -v
ninja explain: output ImageFilter/cargo-prebuild_image_filter of phony edge with no inputs doesn't exist
ninja explain: output ImageFilter/CMakeFiles/_cargo-build_image_filter doesn't exist
ninja explain: ImageFilter/CMakeFiles/_cargo-build_image_filter is dirty
ninja explain: ImageFilter/cargo-prebuild_image_filter is dirty
ninja explain: ImageFilter/CMakeFiles/_cargo-build_image_filter.util is dirty
ninja explain: ImageFilter/_cargo-build_image_filter is dirty
ninja explain: ImageFilter/libimage_filter.a is dirty
ninja explain: imageviewer-app is dirty
ninja explain: ImageFilter/cargo-build_image_filter is dirty
ninja explain: output _deps/corrosion-build/all of phony edge with no inputs doesn't exist
ninja explain: _deps/corrosion-build/all is dirty
ninja explain: ImageFilter/all is dirty
[0/3] cd /home/milian/projects/kdab/training-material/addon/rust-cxx-qt/sol-imageviewer-cxx/ImageFilter && /usr/bin/cmake -E env CXX_x86_64_unknown_linux_gnu=/home/milian/.bin/g++ AR_x86_64_unknown_linux_gnu=/home/milian/.bin/ar CORROSION_BUILD_DIR=/home/milian/projects/kdab/training-material/addon/rust-cxx-qt/sol-imageviewer-cxx/build/ImageFilter CARGO_BUILD_RUSTC=/home/milian/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc /home/milian/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo rustc --lib --target=x86_64-unknown-linux-gnu --package image_filter --manifest-path /home/milian/projects/kdab/training-material/addon/rust-cxx-qt/sol-imageviewer-cxx/ImageFilter/Cargo.toml --target-dir /home/milian/projects/kdab/training-material/addon/rust-cxx-qt/sol-imageviewer-cxx/build/./cargo/build --locked -- -Cdefault-linker-libraries=yes
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.03s
[2/3] cd /home/milian/projects/kdab/training-material/addon/rust-cxx-qt/sol-imageviewer-cxx/build/ImageFilter && /usr/bin/cmake -E make_directory /home/milian/projects/kdab/training-material/addon/rust-cxx-qt/sol-imageviewer-cxx/build/ImageFilter && /usr/bin/cmake -E copy_if_different /home/milian/projects/kdab/training-material/addon/rust-cxx-qt/sol-imageviewer-cxx/build/./cargo/build/x86_64-unknown-linux-gnu/debug/libimage_filter.a /home/milian/projects/kdab/training-material/addon/rust-cxx-qt/sol-imageviewer-cxx/build/ImageFilter

Is there any chance to improve this?

[jschwe]

Is your issue the noise this creates on the commandline? Under the hood corrosion just wraps cargo, which doesn't recompile anything, and dependant C targets should also not be recompiled or relinked since the byproducts have not changed.

The reason is that corrosion uses add_custom_target for the cargo build invocation. Custom targets are considered always out of date.
The alternative would be to use a custom command instead, and specify the DEPFILE that cargo emits. I believe I already tried this though and ran into some issue with specifying the output files / byproducts of the custom command, due to some required generator expressions not being allowed to be used in this context.

Edit: https://github.com/corrosion-rs/corrosion/blob/master/cmake%2FCorrosion.cmake#L850
I believe this comment documents the reason: basically the hostbuild feature of corrosion prevents us from doing this (more accurately, specifying hostbuild mode via target properties).

[milianw]

Me and my colleagues consider always-dirty targets a wart that ideally get fixed. And yes, that means one shouldn't use add_custom_target for exactly that reason. I understand it's complicated in your situation, so if this is closed as WONTFIX so be it.

Before you do that though: If the "hostbuild feature" is the reason for this wart, and we are not using it - would it be possible to tweak corrosion to use the clean approach with custom commands for us, and only use the current always-dirty approach when needed for the hostbuild feature? Something like a set(CORROSION_DISABLE_HOSTBUILD ON) or similar on our end, and when you pick that up you could disable the hostbuild macros and use custom commands instead of targets?