1560981 - use the bindgen executable for stylo rather than building bindgen at build time

Status: NEW

(Core :: CSS Parsing and Computation, task, P3)

Description

[Nathan Froyd [:froydnj]]

At Whistler, when considering alternate ways of speeding up the build rather than boiling the ocean, one idea I had was using the bindgen executable nowadays, rather than building all of bindgen (and the bindgen executable, which contains ridiculously expensive crates to compile, like clap) and being subject to:

• compiling in debug mode and having bindgen execute slowly; or
• compiling in release mode and waiting for bindgen to compile.

There might not be sufficient support in the bindgen executable for all the things we do, but we could add all that, and maybe we could even make a few things more efficient (the fixup stuff for stylo does not look super-efficient, for instance).

Does this seem at all reasonable? If we did it for stylo, we'd probably want to do the same thing for cranelift as well.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Yes, it does. Some comments:

• clap is a bit annoying indeed, but we could avoid building it with a bit of effort I'd think... https://github.com/rust-lang/rust-bindgen/pull/1111
• We use bindgen less and less for stylo these days, we should be able to speed it up just by reducing the amount of stuff it includes. I was planning to look at that anyway, there's a whole lot of stuff that probably doesn't need to be included.
• Most of what you can do on the library you can do with the CLI tool, though it's quite ugly, we may want to add a toml configuration file or something that you can use with the CLI rather than flags. Not particularly trivial and probably not blocking.

Comment 2

[Benjamin Bouvier [:bbouvier] (inactive)]

Agreed that Cranelift could make use of this; our build step for bindings doesn't do anything complicated, at all. This would also make the situation more symmetric with cbindgen, where the executable is used at build time. (Not sure about this, but maybe it also means we don't need builders to depend on clang dev libs, which is nice? among many other libs)