On Mon, May 9, 2016 at 11:31 PM, Jack Moffitt <[email protected]> wrote:
> > 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? > > Generally you'd make a corresponding change to the Rust bindings > immediately and we'd have unit tests for them that ensured they > worked. This will only break downstream users if they are pointed > directly to the github repo as their dependency *and* they are not > pointed at a specific working revision. > In the ideal - and common - case, this shouldn't be a manual process: most of the bindings are auto-generated. Ideally, the script doing this would run in automation and, e.g., upload the generated bindings to archive.mozilla.org, similar to how jsshell bundles are uploaded there. (E.g. https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/) The main reason why having this in-tree would be nice is that much of the breakage in the bindings is caused by using C++ features that're too clever for the bindings generator and hence need annotations or dumbing-down. If during automation the bindings were generated and perhaps a very simple Rust embedding compiled (such as the tests in [1] or the stupendously bare-bones shell in [2]) that should alleviate 90% of the pain that's currently associated with updating Servo's SpiderMonkey. The bindings generator is a Rust application itself: https://github.com/crabtw/rust-bindgen It should be pretty straight-forward to install this on our build servers: they already have all the preconditions available. I think most of the work involved in getting this working is in getting the bindings working with current mozilla-central without patches, and in releng. The former entails (cleaning up and) landing a bunch of patches we currently have in the mozjs github repo[3]. > Currently rust-mozjs is not published to crates.io, so keeping it > compiling and writing some unit tests and ensuring those are part of > normal js automation is probably all that is needed right now. If we > wanted to publish to crates.io we'd need to occasionally update the > version info and do a cargo publish at some regular cadence. If we had everything needed to create the bindings in mozilla-central and published to crates.io, we wouldn't even need a repository for mozjs at all: creating a new release would entail testing that it works, fixing any potential issues (with patches landed in mozilla-central), bumb the version (again with a patch landed in mozilla-central), and publish to crates.io. mozilla-central would remain the one source of truth for SpiderMonkey instead of the current situation where we effectively have a fork in the mozjs repo. To be clear, under this proposal the Servo team would be on the hook for very quickly helping out with regressions to the bindings generation process itself, and for fixing (potentially with help by SpiderMonkey peers) issues with Servo's usage of said bindings when it comes to deploying a new version to crates.io. Till [1] https://github.com/servo/rust-mozjs/tree/master/tests [2] https://github.com/tschneidereit/mozjs-shell [3] https://github.com/servo/mozjs/compare/85a4f5fcaae2ccd08233d4208d387243483fed40...master _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
