Fix installation when ZENOHC_CUSTOM_TARGET is not set and CARGO_BUILD_TARGET env variable is set

[traversaro]

In the case ZENOHC_CUSTOM_TARGET is not set, no --target option is passed to cargo build, but a given target can be set with the CARGO_BUILD_TARGET env variable. In that case the locatio of the library depends on the specified CARGO_BUILD_TARGET env variable. This PR adds a logic branch to handle this case, and avoid the error:

CMake Error at install/cmake_install.cmake:51 (file):
  file INSTALL cannot find
  "/home/conda/staged-recipes/build_artifacts/libzenohc_1719160267267/work/target/release/libzenohc.so":
  No such file or directory.
Call Stack (most recent call first):
  cmake_install.cmake:47 (include)

if CARGO_BUILD_TARGET env variable is set.

[traversaro]

See rerun-io/rerun#5547 for a similar PR.

[DenisBiryukov91]

@traversaro Does it really makes sense to account for cargo env variable when building a technically c-package? I understand that we heavily use cargo in build process, and that this env variable indeed might be set, maybe it is better to produce a error message if we detect that CARGO_BUILD_TARGET is set and ZENOHC_CUSTOM_TARGET is not (or different from ZENOHC_CUSTOM_TARGET) ? Or alternatively force-set ZENOHC_CUSTOM_TARGET to the same value as CARGO_BUILD_TARGET (and produce a diagnostic message) ?

[traversaro]

@traversaro Does it really makes sense to account for cargo env variable when building a technically c-package? I understand that we heavily use cargo in build process, and that this env variable indeed might be set, maybe it is better to produce a error message if we detect that CARGO_BUILD_TARGET is set and ZENOHC_CUSTOM_TARGET is not (or different from ZENOHC_CUSTOM_TARGET) ? Or alternatively force-set ZENOHC_CUSTOM_TARGET to the same value as CARGO_BUILD_TARGET (and produce a diagnostic message) ?

Just to give you a bit more context on this change, I encountered this when building a conda-forge package for zenoh-c in conda-forge/staged-recipes#26736 . In there, the CARGO_BUILD_TARGET is set automatically when building rust packages by the build environment, so I encounted this problem. I could have solved by just setting ZENOHC_CUSTOM_TARGET equal to the CARGO_BUILD_TARGET env variable, but I thought other could experience my problem eventually.

maybe it is better to produce a error message if we detect that CARGO_BUILD_TARGET is set and ZENOHC_CUSTOM_TARGET is not (or different from ZENOHC_CUSTOM_TARGET) ?

Yes, that can be done, if you like I can implement it.

Or alternatively force-set ZENOHC_CUSTOM_TARGET to the same value as CARGO_BUILD_TARGET (and produce a diagnostic message) ?

I would avoid that. diagnostic messages are frequently ignored, and the final net effect would be for ZENOHC_CUSTOM_TARGET to be ignored if CARGO_BUILD_TARGET is set, that does not seem super intuitive.