Cross-compile from Linux to macOS?

[SimonSapin]

RustAudio/coreaudio-sys#28 does it for a smaller Rust project. This would likely involve non-trivial work in the build.rs file of each dependency that compiles non-Rust code.

On CI we may want to keep some build tasks on macOS to check that they keep working, but switching at least the release build used for WPT to be compiled on Linux with many more CPU cores could help significantly reduce Homu’s cycle time.

[jdm]

Gecko does this:

• https://searchfox.org/mozilla-central/source/taskcluster/ci/build/macosx.yml#5-45
• https://wiki.mozilla.org/Building_Firefox/SURF#How_do_I_modify_the_compiler_used_to_build_Firefox.3F

[SimonSapin]

likely involve non-trivial work in the build.rs file of each dependency that compiles non-Rust code.

Maybe it’s not too terrible. This was enough to successfully cross-compile the tinyfiledialogs crate with CC=clang:

--- build.rs
+++ build.rs
@@ -12,6 +12,8 @@ fn main() {
     cc::Build::new()
         .file("libtinyfiledialogs/tinyfiledialogs.c")
         .flag("-v")
+        .flag("-isysroot")
+        .flag("/home/simon/tmp/macos-sdk/MacOSX10.13.sdk")
         .compile("libtinyfiledialogs.a");
 
     if target.contains("windows") {

Of course when doing this "for real" we’d make it conditional on $TARGET and probably pass the SDK path through an environment variable. And maybe we could do it in the cc crate, so that tinyfiledialogs and other crates that use cc in a "simple enough" way might not need any change.

But there’s significant of variety in build script in all of Servo’s recursive dependencies, many compile C or C++ code without the cc crate and would need individual changes to pass the SDK path. So completing this would still take spending time adapting multiple build system.