There's an effort to add Rust code to SpiderMonkey: https://bugzilla.mozilla.org/show_bug.cgi?id=1490948
This will introduce a jsrust_shared crate that will just depend on all the Rust crates that SpiderMonkey needs like gkrust_shared depends on the crates the rest of Gecko needs. This is fine both for building standalone SpiderMonkey (a top-level jsrust will produce a .a and depend on jsrust_shared) and SpiderMonkey as part of libxul (gkrust_shared will depend on jsrust_shared). However, there exists a third configuration: --enable-shared-js. With this option, SpiderMonkey is linked dynamically instead of being baked into libxul. This is fine as long the set of FFI-exposing crates that SpiderMonkey depends on and the set of FFI-exposing crates that the rest of Gecko depends on are disjoint. If they aren't disjoint, a symbol conflict is expected. AFAICT, this could be solved in at least three ways: 1) Keeping the sets disjoint. If both SpiderMonkey and the rest of Gecko want to call the same Rust code, introduce a differently-named FFI binding for SpiderMonkey. 2) Making FFI symbols .so-internal so that they don't conflict between shared libraries. Per https://bugzilla.mozilla.org/show_bug.cgi?id=1490603 , it seems that this would require rustc changes that don't exist yet. 3) Dropping support for --enable-shared-js For my immediate use case, I want to make 4 functions available both to SpiderMonkey and the rest of Gecko, so option #1 is feasible, but it won't scale. Maybe #2 becomes feasible before scaling up #1 becomes a problem. But still, I'm curious: How important is --enable-shared-js? I gather its use case is making builds faster for SpiderMonkey developers. Is that the only use case? Is it being used that way in practice? -- Henri Sivonen hsivo...@mozilla.com _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
