Replied inline. Please reply to all because I'm not in dev-tech-js-engine-internals btw.
PS: That was first sent to me on "[email protected]" which apparently doesn't work. > Le 9 mai 2016 à 22:37, Jim Blandy <[email protected]> a écrit : > > Hi, folks. How does the SpiderMonkey team feel about moving the Servo > project's Rust JSAPI bindings from the separate github repo they're in now > into js/src in Mozilla Central? > > Two weeks ago I posted a message, "Rust bindings for Debugger API", pointing > folks at the discussion in bug 1263317 about adding a Rust API for > SpiderMonkey's debugging facilities. Since then we've learned two interesting > things: > > First: Because of the way Rust crates are compiled and linked, it's difficult > to have one Rust API (rust-mozjs) located in a separate crate, and another > Rust API (for the debugger) located in js/src, as originally discussed. > Everything would be much easier if there could be a single crate providing > Rust bindings for the SpiderMonkey library. (Anthony, could you follow up > with more details here?) So we have two things: mozjs [1], which packages a SM tarball as a Rust crate and instructs Cargo on how to link against libjs_static. rust-mozjs [2], which depends on the former and includes safe wrappers for some JS APIs and the bindings, which we generate from parsing SM's C++ code with a fork of rust-bindgen [3][4][5]. > Second: Servo is finding their periodic updates to the latest SpiderMonkey to > require exorbitant amounts of work. At present, an engineer needs to dedicate > an entire quarter to it, which is completely untenable. Having the Rust API > be treated as just another build and test in SpiderMonkey's ordinary CI > processes would be a huge improvement: problems could be addressed as they > arise. The problem is that we put into the Git repository the bindings for all the platforms we handle, so that would mean that committers would somehow need to update each version of the bindings (currently there are 8 of them) every time they change something. That's not scalable. I have two solutions in mind: - We stop putting in Git the bindings generated before-hand, at upgrade-time, and we start depending on rust-bindgen (and thus libclang) at compile-time (that would mean that SM developers too would need libclang to work on SM if the bindings are put there). - We don't upstream the bindings at all, but we make a complete, scalable bindgen tool that can generate for any target we need, by behaving like a cross compiler, where we would "only" need to provide system/libc headers for the targets we are interested in. That should probably be a quarter goal, and I think for that to work we would need to make bindgen a proper Research project. After all it's not like it would hurt Rust to be able to talk with C, C++ and Objective-C. That could even supersede our own Cocoa bindings and maybe the winapi stuff too. I see on Google Groups that Jason Orendorff had some questions too, replying here. > What *should* happen if we add a parameter to a JSAPI function? Should we > add it to the rust-mozjs equivalent at the same time, immediately breaking > downstream users? The bindings are generated, so the parameter would be added when updating mozjs and rust-mozjs. That's really not the blocking part of making a SpiderMonkey update. > Who's doing the "release engineering", and what's involved? Just bumping > version numbers and running `cargo publish` from time to time? I did the last SM upgrade. What was involved: - Generate an SM tarball from mozilla-central's tip with make-source-package.js - Excitement. - Try to compile that. - Install an Ubuntu VM to setup libclang and Rust and mozjs to generate bindings for Linux 32 for our Android target. - Ask a third party to generate bindings for Linux 64 while I'm busy with Linux 32. - Despair. - Install Windows to setup libclang and Rust and mozjs to generate bindings for Windows. - Fix a few linking issues on Linux 32. - Fix some issues where the tarball is missing some things on Windows because m-c has no CI for that. - Fix a few linking issues on Windows related to some msys/mingw insanity. - Suffering. - Patch some C++ code so that our bindgen tool can cope with it. - Patch the code in Servo to use the new SM. - Land. Oh and did I mention that there are 8 versions of the bindings? We support 4 platforms, but enabling JS_DEBUG means we need another set of bindings because some structs change layout, and some functions are defined only with JS_DEBUG. We don't publish rust-mozjs because we are its only user for now and we don't claim anything about the usefulness of our current setup. I hope I'm making sense and that replies all of your questions. _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
