On Fri, Oct 28, 2016 at 3:04 AM, Xidorn Quan <quanxunz...@gmail.com> wrote:
> 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. > If we have to build rust-bindgen because the versions in distros aren't sufficient, then that should be a valid reason to require libclang. Slightly off topic: since rust-bindgen isn't stable enough, does this mean we'll be vendoring it in mozilla-central? (I think it will.) Another benefit of requiring libclang is we can start leaning more heavily on the Clang tooling ecosystem. I'd love to have more widespread use of things such as automatic rewriting of source code to conform with our style conventions. I'm not sure if this requires libclang per se. But having Clang/libclang everywhere gets us one step closer. > > 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 >
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
