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.
A crate is a compilation unit. It's not configurable.