Co-authored-by: Jade Lovelace <jadel@mercury.com> Change-Id: I026f271b07c9e27012f9ee1c16a2a1f4ba7f6ba3
What the hell is this?
This is a cursed solution to the intersection of the following problems:
- Lix is separated into multiple libraries, which are intended to be buildable as dynamic/shared libraries or statlic libraries.
- Those libraries are linked into the Lix executable binary.
- Static libraries also statically link their library dependencies.
- We want to be able to use Rust code in multiple places in the codebase.
- Meson has poor support for Rust and non-Rust sources in the same target, with internal errors preventing mixed targets from linking against non-mixed targets.
- Linking more than one Rust
crate-type = staticlibis unsupported with Rust's standard library. - Meson does not support dynamically linking the Rust standard library for
crate-type = staticlib. - Meson ignores
link_argsfor Rust targets - Meson does not set soname of Rust cdylibs
So! What do we do? For any Rust code that Lix wants to use, we always link to a single crate, which will reëxport Rust code from any crate (in-tree or out-of-tree) we wish to use.
This "monocrate" is always built as a static library, and anything in Lix that depends on Rust code will statically link it in.
When the Lix executable is linked against Lix libraries that are built statically, we do not link_whole them.
As far as we::Qyriad can tell, this is sufficient to not break everything.
But long-term, we should probably solve this problem by migrating to Rust code at top-level, and having Rustc do the final link.