← Back to context

Comment by zozbot234

6 years ago

>But allowing crate writers to opt into a stable ABI would be beneficial for precompiled crates as well as compile times

I think there is already a fuzzy convention that could basically be made to enable this. A crate name ending in -sys is expected to provide a C-like interface, and to thus be usable in a dylib context, whereas the same crate name with no suffix or with a -rs one provides a statically-linked, ABI-unstable wrapper to its corresponding -sys. The build system just needs to be made aware that the former kind of crate need not be recompiled when potential ABI-breaks are introduced.

> (a crate is a Rust package)

A crate is a Rust compilation unit. Closer to a .cxx, .o file in C/C++ than what are usually called "packages" there.

-sys are raw wrappers around C code so wouldn't provide much benefit for them to be exposed as dynlibs.

And crates are the equivelant of python, node, go, etc packages. That they are also a compilation unit is, I believe, an implementation detail. I think they also made it configurable.

  • A crate is a compilation unit. A package is defined by a Cargo.toml, and can have one or more crates.

    Most folks use “package” and “crate” interchangeably, even if they’re technically different.

    See the bottom of https://doc.rust-lang.org/book/ch07-00-managing-growing-proj...

    (Additionally, “compilation unit” is a bit weird, given incremental compilation, etc. “the file containing the root module tree that gets passed to rustc” is not as succinct though.)

  • We can split one crate into multiple units for better paralleization, but I don't think there is a way to put multiple into a single compilation unit.