On Mon, Sep 24, 2018 at 11:04:43AM +0300, Henri Sivonen wrote: > 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?
for _Gecko_ developers. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
