Use different target-dir for each package or enable workspace target-dir

[kanru]

Currently all the cargo-build targets use the same cargo_target_dir "${CMAKE_BINARY_DIR}/${build_dir}/cargo/build"

In my case a workspace with multiple packages, this always causes rebuilding each package for each build.

Ideally packages in the same workspace should be able to share artifacts but I'm not sure if it's easy to do. At least if we change the cargo_target_dir to something like "${CMAKE_BINARY_DIR}/${build_dir}/cargo/${package_name}/target" then each package can reuse their artifact at the cost of building each dependency once.

[jschwe]

In my case a workspace with multiple packages, this always causes rebuilding each package for each build.

Are you perhaps setting different rustflags for each package (e.g. via corrosion_add_target_rustflags())? If possible consider using corrosion_add_target_local_rustflags which only changes the rustflags for the main crate, but not dependencies.

If you are not setting any rustflags I would need some more information to be able to reproduce your problem. At work we also use a large workspace and are not experiencing this problem with corrosion.

[kanru]

Thanks for reply! I don't have a minimum reproducible repository yet, the repository I'm working on is this branch https://github.com/chewing/libchewing/tree/rust

I'm not setting any rustflags. The structure of my workspace is like this

libchewing [root package]
|- src [both c and rust files]
|- capi/chewing-internal [staticlib package, depends on the root package]
`- tools [bin package]

The final target libchewing.so is chewing-internal linked with some C object files. And the tools package is used to build static data files.

For each build, the tools and the chewing-internal package will clobber each others' build dir and cause rebuild.

[jschwe]

I checked out the rust branch of your project, but can't reproduce. The rust libraries compile fine and don't recompile when retrying, however the C code fails to compile due to some warnings. I tried configuring cmake like this:

 cmake -S. -Bbuild -GNinja -DMAKEINFO=/opt/homebrew/bin/makeinfo --compile-no-warning-as-error
cmake --build build

[kanru]

I created this minimum reproducer https://github.com/kanru/corrosion-issue-309

It looks like it's caused by the lib member and the bin member both depending on the root package. If I remove the dependency from the bin member then I can no longer reproduce.

Test setup

git clone https://github.com/kanru/corrosion-issue-309

cd corrosion-issue-309
mkdir build
cmake -G ninja ..
ninja

Expected: run second ninja should not rebuild everything
Actual: each ninja run will always rebuild both the lib and bin

[jschwe]

Thanks for the minimal example! This is a regression most likely introduced by commit fa4e241 -CARGO_TARGET_<xxx>_LINKER seems to cause the recompiles if it differs.
Since you are not using C++ (as far as I can tell), you can fix this for the moment by simply adding the option NO_LINKER_OVERRIDE when calling corrosion_import_crate()

[kanru]

Thanks. Related PR: #270 #272

I can confirm that adding NO_LINKER_OVERRIDE fixes the issue for now. I do plan to build the library on Windows and eventually let Rust produce the cdylib, not sure if this will cause issues.

Btw, I notice the doc for NO_LINKER_OVERRIDE and PROFILE option is reversed in the README.md file.

[jschwe]

I do plan to build the library on Windows and eventually let Rust produce the cdylib, not sure if this will cause issues.

Windows and cdylib or not should not really affect this issue. It only matters if you link C++ code into your Rust executable. In the medium term I hope to resolve this with #310.

[jschwe]

Closing - The immediate issue was already solved. Tracking the possibility of overrding the target-dir per cmake target in issue #328