Currently we distribute a shared library for each internal rustc library we have. However, ultimately, what really needs to be exposed are two symbols main
for rustc and main
for rustdoc; everything else may be as private or internal as they need to be.
High level proposal is to instead ship a large librustc_everything.so
/rustc_everything.dll
/etc shared library and two ultra-thin binaries which essentially are
#[link="rustc_everything"]
extern "Rust" { fn rustc_main(); }
fn main() {
rustc_main();
}
rustc_everything
would link all the libraries we currently ship statically and only export the two entry points for rustc and rustdoc (potentially others for whatever other tools we would produce).
This proposal, would help us with enforcing our stability story. Currently you can link to the librustc_*
libraries with plain -l
circumventing any stability checks and thus increasingly de facto stabilising crates we do not want to stabilise (most notably I myself experimented heavily in that direction with the llvm_build_utils crate and librustc_llvm
library). It allows us to hide stuff like rustc-internal serialize
or getopts
as well.
That being said, what I’m proposing here is obviously a breaking change. It breaks anybody linking to rustc crates via -l
. And it breaks anybody using extern crate getopts
without cargo and with the unstable(rustc_private)
.
I’m still not entirely sure how this would work with syntax extensions, though. Do they need (some) internal crates exposed to have what to link to? At runtime they obviously could just use what’s already loaded into the process space, but what about compile time? We could have rustc_stuff_for_syntax_extensions
and rustc_everything_else
, or rustc_everything
could selectively re-export crates necessary for syntax extensions.