On Friday, October 28, 2016 at 1:57:39 PM UTC+11, Bobby Holley wrote: > On Thu, Oct 27, 2016 at 7:45 PM, Mike Hommey <m...@glandium.org> wrote: > > > On Thu, Oct 27, 2016 at 07:38:27PM -0700, Bobby Holley wrote: > > > On Thu, Oct 27, 2016 at 7:21 PM, Mike Hommey <m...@glandium.org> wrote: > > > > > > > On Thu, Oct 27, 2016 at 07:11:10PM -0700, bobby...@gmail.com wrote: > > > > > On Thursday, October 27, 2016 at 4:41:30 PM UTC-7, Nathan Froyd wrote: > > > > > > On Thu, Oct 27, 2016 at 7:31 PM, Chris Peterson > > > > > > <cpet...@mozilla.com> wrote: > > > > > > > The Stylo team would like to make libclang a build-time dependency > > > > > > > so we can generate C++/Rust bindings as part of the local build. > > > > > > > > > > > > What is the benefit of doing this, especially for people not working > > > > > > on Stylo? > > > > > > > > > > For stylo, we generate Rust representations for all sorts of C++ data > > > > > structures. If those memory layouts are wrong, it's a memory hazard. > > > > > > > > > > If we don't generate the bindings at build time, we would need to > > > > > check them into the tree, which means that developers would need to > > > > > manually run the binding generator any time they changed a bound data > > > > > structure (including all sorts of stuff in xpcom, MFBT, dom, and > > > > > layout). Forgetting to do this would be sec-critical, and people will > > > > > most certainly forget. And even if they didn't, it would be a huge > > > > > PITA. > > > > > > > > Why are we considering a dependency on libclang instead of one on > > > > rust-bindgen? > > > > > > > > > > Because rust-bindgen depends on libclang. > > > > So what? What developers need is rust-bindgen, not libclang. They can > > get rust-bindgen through different means. That may have required > > building libclang, or installing libclang development files, or > > installing a prebuilt rust-bindgen, or whatever, and the build system > > doesn't have to care about that. > > > > In fact, rust-bindgen could (hypothetically) switch to a different C/C++ > > parser, and the build system would still depend on rust-bindgen, but not > > libclang. > > > > So again, why are we considering a dependency on libclang instead of one > > on rust-bindgen? > > > If that kind of abstraction makes things easier somehow, that's fine by me. I > care about the observables. > > > I'm kind of skeptical though. rust-bindgen is a very small rust crate, and > doesn't publish any prebuilt binaries to speak of. libclang is huge and has > prebuilt binaries that are accessible via package managers. Naively, it would > seem most practical to require libclang, vendor rust-bindgen in tree along > with all our other rust dependencies, built rust-bindgen with gecko, and use > it to generate the bindings.
Another thing is that, rust-bindgen hasn't been stable enough for being delivered via prebuilt version. We constantly find issues on it and patch it when necessary. This would likely continue to happen in a reasonable time. Sometimes latest code may require bindings generated from the latest revision of rust-bindgen to work. Given this, I believe it would be better to pin its revision in-tree as part of the build, rather than deliver a prebuilt version separately. Otherwise, people may need to upgrade it frequently to have it work with latest source code. In addition, I think it makes the most of sense to make rust-bindgen a build dependency of servo/geckolib (or probably servo/style) directly, so that we do not need an additional python script to call a separate binary, and play with the path. We can do that altogether inside build.rs. - Xidorn _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
