Set the rpath to Qt for Rust binaries

For C++ apps we apply rpath to the cdylib implicitly via qttypes, but
link flags for rust binaries are not transitively propagated but require
explicit opt-in by the top-level crate. However we want that
convenience, to avoid Rust apps having to deal with Qt backend specific
code in their build.rs. Therefore we use the _DEP mechanism to get the
qt library path from the qttypes crate and write it into a generic file
in the qt backend's build.rs, which is then picked up by sixtyfps-build.

We'll use the same mechanism to propagate link flags for the MCU build
(such as the linker script).

cc #566

Author: tronical

api/sixtyfps-rs/sixtyfps-build/lib.rs

@@ -269,5 +269,25 @@ pub fn compile_with_config(
     println!("cargo:rerun-if-env-changed=SIXTYFPS_STYLE");
 
     println!("cargo:rustc-env=SIXTYFPS_INCLUDE_GENERATED={}", output_file_path.display());
+
+    apply_linker_flags();
+
     Ok(())
 }
+
+// Backends such as Qt or the MCU might need special link flags. We don't want to require users to have to
+// deal with those, so propagate them here.
+fn apply_linker_flags() {
+    // Same logic as in sixtyfps-rendering-backend-qt's build script to get the path
+    if let Some(path) = std::env::var_os("OUT_DIR").and_then(|path| {
+        Some(Path::new(&path).parent()?.parent()?.join("SIXTYFPS_BACKEND_LINK_FLAGS.txt"))
+    }) {
+        // unfortunately, if for some reason the file is changed, it is changed after cargo decide to re-run
+        // this build script or not. So that means one will need two build to settle the right thing.
+        println!("cargo:rerun-if-changed={}", path.display());
+
+        if let Ok(mut link_flags_file) = std::fs::File::open(path) {
+            std::io::copy(&mut link_flags_file, &mut std::io::stdout()).ok();
+        }
+    }
+}

sixtyfps_runtime/rendering_backends/qt/build.rs

@@ -38,9 +38,11 @@ fn main() {
     // Ref: https://docs.microsoft.com/en-us/cpp/build/reference/utf-8-set-source-and-executable-character-sets-to-utf-8
     config.flag_if_supported("/utf-8");
 
+    let qt_library_path = std::env::var("DEP_QT_LIBRARY_PATH").unwrap();
+
     if cfg!(target_os = "macos") {
         config.flag("-F");
-        config.flag(&std::env::var("DEP_QT_LIBRARY_PATH").unwrap());
+        config.flag(&qt_library_path);
     }
     config.include(std::env::var("DEP_QT_INCLUDE_PATH").unwrap()).build("lib.rs");
 
@@ -58,4 +60,28 @@ fn main() {
     println!("cargo:rerun-if-changed=qt_widgets/tabwidget.rs");
     println!("cargo:rerun-if-changed=lib.rs");
     println!("cargo:SUPPORTS_NATIVE_STYLE=1");
+
+    // Cargo doesn't support implicit transitive link flags for crates (https://github.com/rust-lang/cargo/issues/9554 | https://github.com/rust-lang/cargo/issues/9562 | https://github.com/sixtyfpsui/sixtyfps/issues/566).
+    // Instead of requiring Rust apps to have Qt backend specific code, write the needed rpath link options into a file that sixtyfps-build can find later.
+    // For C++ apps that's not an issue because we create a cdylib, qttypes emits `rustc-cdylib-link-arg` and that *is* propagated.
+    // This also means that the Qt backend cannot be combined with another backend that also writes to this file. The GL backend doesn't, but the MCU
+    // backend might/will.
+    let link_flags =
+        if std::env::var("CARGO_CFG_TARGET_FAMILY").as_ref().map(|s| s.as_ref()) == Ok("unix") {
+            format!("cargo:rustc-link-arg=-Wl,-rpath,{}", &qt_library_path)
+        } else {
+            String::new()
+        };
+
+    let out_dir = std::env::var_os("OUT_DIR").unwrap();
+    // out_dir is something like
+    // <target_dir>/build/sixtyfps-rendering-backend-qt-1fe5c4ab61eb0584/out
+    // and we want to write to a common directory, so write in the build/ dir
+    let target_path = std::path::Path::new(&out_dir)
+        .parent()
+        .unwrap()
+        .parent()
+        .unwrap()
+        .join("SIXTYFPS_BACKEND_LINK_FLAGS.txt");
+    std::fs::write(target_path, link_flags).unwrap();
 }