I ran into a cross-compiling issue where cmake
used the host's CMAKE_SYSTEM_PROCESSOR
instead of the target's and incorrectly evaluated a condition in the CMakeLists.txt
that led to some unsupported compiler flags being used.
After thinking for a bit about how to deal with this issue in general, I can see a couple of solutions:
- Use a
CMAKE_TOOLCHAIN_FILE
(#10) as suggested by the CMake CrossCompiling wiki page
- Set the
CMAKE_SYSTEM_NAME
and CMAKE_SYSTEM_PROCESSOR
in the build.rs
for each target triplet that I need
The first seems too involved if I only need the second, but the second seems like it should be something not specific to my crate since it only depends directly on the $TARGET
.
(Also, let me add as a warning that I am by no means very knowledgeable about CMake, so there may be other reasonable ways to do this.)
I see that there is some support for cross-compiling to certain targets in cmake-rs
already (e.g. a9f74a4, #35, #45), but it seems to be done on a case-by-case basis. Plus, there appears to be a large amount of target-specific logic
So, this has led me to wonder if the cmake-rs
cross-compiling/target-specific story could be improved and extended to support more targets in a relatively clean way. I'm posting this issue basically to see if there's interest and to discuss ideas. Here are some thoughts on different approaches:
-
Leave cmake-rs
mostly untouched and continue to add special cases for various targets.
-
Create a sort of condition matrix to support combinations in a regular way. For example, you might start with host == target
and host != target
and branch within those into different supported targets.
-
Remove all or most of the target-specific logic and put it into CMAKE_TOOLCHAIN_FILE
s, one for each of the different cases supported.
I suppose the latter two options have in common a mapping from Rust target triples to (at least) CMAKE_SYSTEM_NAME
/CMAKE_SYSTEM_PROCESSOR
pairs, though the Rust one may be more explicit. (I'm certainly not the first person to think of this: rust-lang/rust#50220 (comment))
There are a few other improvements (at least, I think they are) that might also be considered (now or in some distant future):
- Use
$CARGO_CFG_TARGET_OS
, $CARGO_CFG_TARGET_ARCH
, etc. instead of $TARGET
- CI with
cross
, perhaps in the style of trust
- iOS support (e.g.
grpc-sys
)
Anyway, these are just some initial thoughts on the matter. Feedback would be appreciated!