Open Bug 1560981 Opened 4 years ago Updated 1 year ago

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

Categories

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

task

Tracking

()

People

(Reporter: froydnj, Unassigned)

References

Details

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.

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.

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)

See Also: → 1561355
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.