We must vendor rust-bindgen in mozilla-central because the versions in distros aren't sufficient. rust-bindgen depends on libclang (bug 1310852).

P2 because rust-bindgen and libclang are a high priority but they are not immediate blockers for Stylo.

Either this or bug 1302028 needs to depend on bug 1312916, since presumably we'll want to build rust-bindgen as a host binary.

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #2) > Either this or bug 1302028 needs to depend on bug 1312916, since presumably > we'll want to build rust-bindgen as a host binary. We don't need to. We can just use the library part of it and make it a build dependency of style component.

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #3) > (In reply to Ted Mielczarek [:ted.mielczarek] from comment #2) > > Either this or bug 1302028 needs to depend on bug 1312916, since presumably > > we'll want to build rust-bindgen as a host binary. > > We don't need to. We can just use the library part of it and make it a build > dependency of style component. So cross compiles would need to *build* libclang? (or have a cross version of it). Yurk.

(In reply to Mike Hommey [:glandium] from comment #4) > (In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #3) > > (In reply to Ted Mielczarek [:ted.mielczarek] from comment #2) > > > Either this or bug 1302028 needs to depend on bug 1312916, since presumably > > > we'll want to build rust-bindgen as a host binary. > > > > We don't need to. We can just use the library part of it and make it a build > > dependency of style component. > > So cross compiles would need to *build* libclang? (or have a cross version > of it). Yurk. Oh, that's a good question. Build dependencies are used for building build.rs, which is run on the host, so I suppose we don't need a cross version of libclang (not sure how cargo handles that, though), but we may need some care about the arguments we pass to it.

By build.rs, I mean the build script supported by cargo: http://doc.crates.io/build-script.html

We may want to treat rust-bindgen like other toolchain dependencies and inject building it (and libclang) into the TaskGraph. See bug 1313111. This only works for TaskCluster, of course. Depending on how often rust-bindgen changes, we may have to deal with a tooltool manifest until automation is fully transitioned to TaskCluster for scheduling.

Filed https://github.com/servo/rust-bindgen/issues/252 to get rust-bindgen onto crates.io so we can vendor it conveniently. The one problem with that is that |mach vendor rust| (and |cargo vendor|) assumes that you only ever want to vendor dependencies of a package, and never the package itself. So we have two options: 1. Create a placeholder crate in-tree that depends on rust-bindgen, and teach |mach vendor rust| to vendor the placeholder crate's dependencies; or 2. Import rust-bindgen manually (or via a script) and teach |mach vendor rust| to vendor rust-bindgen's dependencies. The second option has the benefit that we can easily put the rust-bindgen code wherever we like, whereas the first one would vendor rust-bindgen's code into |third_party/rust/|, which might not be the most convenient for integrating it into the build process. Or we can just forego vendor'ing it for now, stick the necessary binaries in tooltool, and teach |mach bootstrap| to update it for local build purposes...

(In reply to Nathan Froyd [:froydnj] from comment #8) > Filed https://github.com/servo/rust-bindgen/issues/252 to get rust-bindgen > onto crates.io so we can vendor it conveniently. > > The one problem with that is that |mach vendor rust| (and |cargo vendor|) > assumes that you only ever want to vendor dependencies of a package, and > never the package itself. So we have two options: > > 1. Create a placeholder crate in-tree that depends on rust-bindgen, and > teach |mach vendor rust| to vendor the placeholder crate's dependencies; or > 2. Import rust-bindgen manually (or via a script) and teach |mach vendor > rust| to vendor rust-bindgen's dependencies. Those are not necessary. I'm going to use build.rs to replace regen.py, and invoke rust-bindgen as a lib rather than an executable, so that we get the dependency directly from cargo.

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #9) > Those are not necessary. I'm going to use build.rs to replace regen.py, and > invoke rust-bindgen as a lib rather than an executable, so that we get the > dependency directly from cargo. This would elegantly solve the vendoring issue, and the problem of how to invoke the newly-compiled binary from the build system as well. Thank you!

FWIW, the pr for integrating bindgen into build script is https://github.com/servo/servo/pull/14244

With build time bindgen, this is no longer relevant.

(In reply to Xidorn Quan [:xidorn] (UTC-10) from comment #12) > With build time bindgen, this is no longer relevant. How is this not relevant? We'll still need the bindgen code in the tree to run during the build, no?

(In reply to Nathan Froyd [:froydnj] from comment #13) > (In reply to Xidorn Quan [:xidorn] (UTC-10) from comment #12) > > With build time bindgen, this is no longer relevant. > > How is this not relevant? We'll still need the bindgen code in the tree to > run during the build, no? bindgen will be vendored as a normal dependency automatically like all other dependencies of servo code. No special work would be needed in this bug.