Corrosion is incompatible with Ninja Multi-Config

[humenda]

When I try to build my project with Corrosion and the Ninja Multi-Config generator, I get a mesage like this:

$ cd build && cmake Ninja -G "Multi-Config" ..
[…]
-- Using Corrosion as a subdirectory
-- Configuring done
-- Generating done
-- Build files have been written to: /some/path/build

$ cmake --build . --
ninja: error: 'Debug/cargo/build/x86_64-unknown-linux-gnu/debug/libfoo.a', needed by 'src/bar/Debug/bar', missing and no known rule to make it

If I use -G Ninja, it works. I had this issue with single-conf vs. multi-conf. in my project as well. It usually boils doin to a few generator expressions at places where paths are constructed.

Thanks :-)

[AndrewGaspar]

I went to look into this and remembered that I had run into this before... The issue that makes this "hard" ultimately comes down to the problem that you can't use generator expressions in the BYPRODUCTS part of add_custom_target. Why is that important? Ninja must know which commands produce which outputs. This is fine for single config Ninja, but for multi-config, the "debug" and "release" configurations will put their files in different subdirectories of their build directories - x86_64-unknown-linux-gnu/debug vs. x86_64-unknown-linux-gnu/release.

I initially thought I'd make the "debug" and "release" builds separate custom targets. However, that doesn't work either because once you go to generate the imported targets (e.g. foo, in your case), you can't use generator expressions in the add_dependencies call either - so no add_dependencies(foo $<IF:$<CONFIG:Debug>,cargo-build-debug_foo,cargo-build-release_foo>).

An "easy" solution is to instead use the --out-dir flag to cargo to place debug and release builds in the same relative path. Unfortunately, it's not stable yet, so it would require a nightly rust toolchain: rust-lang/cargo#6790

A harder solution would be to instead copy all the outputs to a different location, which honestly might be a good idea anyway - they should probably go directly in the binary dir. Having to go digging for libs and executables in the cargo output directory is annoying, and is honestly not in the spirit of Corrosion.

[humenda]

I am worried that you experienced the exactly same issues than what I have encountered beginning of this week in my project. Did you try to raise this with the CMake developers? I suppose it could be something that cannot be solved (easily), since dependency management is configuration time :(.

I initially thought I'd make the "debug" and "release" builds separate custom targets. However, that doesn't work either because once you go to generate the imported targets (e.g. `foo`, in your case), you can't use generator expressions in the `add_dependencies` call either - so no `add_dependencies(foo $<IF:$<CONFIG:Debug>,cargo-build-debug_foo,cargo-build-release_foo>)`. An "easy" solution is to instead use the `--out-dir` flag to `cargo` to place debug and release builds in the same relative path. Unfortunately, it's not stable yet, so it would require a nightly rust toolchain: rust-lang/cargo#6790

We could try to raise awareness on the Rust side. Would it be possible to enable this unstable feature using an option? Or would it be too hard to implement two paths?

A harder solution would be to instead copy all the outputs to a different location, which honestly might be a good idea anyway - they should probably go directly in the binary dir. Having to go digging for libs and executables in the cargo output directory is annoying, and is honestly not in the spirit of Corrosion.

Sure, but at least the final build artefact location is stable, isn't it? Did you mean "is not a good idea" :)? I would like to make progress here. The CMake side seems difficult to me because I suspect it's the way CMake is build that this feature is impossible. `--out-dir` seems to be mostly an issue of "how do we handle x" and in the spirit of having an embedded working group, that should be able to be prioritised, if we have good arguments. Thanks

[AndrewGaspar]

OK, so I tried to implement the copying method and discovered that it would not solve the issue of not allowing generator expressions in BYPRODUCTS. I had incorrectly assumed relative paths to BYPRODUCTS would be relative to ${CMAKE_CURRENT_BINARY_DIR}/$<CONFIG>, but it is not... it's relative to ${CMAKE_CURRENT_BINARY_DIR}. Because of that, I think this is definitely blocked on the CMake issue I described.

I'll make a note on the CMake issue.

In the mean time, I'm going to rename this issue - this doesn't affect all multi-config generators, just Ninja multi-config.

[AndrewGaspar]

Looks like this will be supported in CMake 3.20: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5402

[humenda]

Great news.

[ratijas]

CMake 3.20.0 was released few weeks ago. If it indeed fixed the issue, then the Corrosion's generator check regarding Ninja Multi-Config could be extended to check for compatible CMake version.

https://github.com/AndrewGaspar/corrosion/blob/4a1dbd27ee693b3ee093b7dc601a2019f728d5e8/cmake/Corrosion.cmake#L3-L7

[SchrodingerZhu]

How is this going now? on 3.22 it seems that Ninja and Ninja Multi-Config are both broken

[ogoffart]

Could you specify what you mean by "broken" ?

[tronical]

How is this going now? on 3.22 it seems that Ninja and Ninja Multi-Config are both broken

I'm using 3.22 with a corrosion based project and ninja 1.10.0 and it seems fine. What errors are you encountering?

[SchrodingerZhu]

it was showing the exact error as above. I will upload some logs later

[SchrodingerZhu]

it was showing the exact error as above. I will upload some logs later

[tronical]

Ahh, great - yes please :). Please also include the command line you're using to invoke cmake. Do you have a CMAKE_GENERATOR environment variable set, by chance?