| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Also helps provide context if it fails.
|
|
The `rust-std` package that we produce is expected to have not only the standard
library but also libtest for compiling unit tests. Unfortunately this does not
currently happen due to the way rustbuild is structured.
There are currently two main stages of compilation in rustbuild, one for the
standard library and one for the compiler. This is primarily done to allow us to
fill in the sysroot right after the standard library has finished compiling to
continue compiling the rest of the crates. Consequently the entire compiler does
not have to explicitly depend on the standard library, and this also should
allow us to pull in crates.io dependencies into the build in the future because
they'll just naturally build against the std we just produced.
These phases, however, do not represent a cross-compiled build. Target-only
builds also require libtest, and libtest is currently part of the
all-encompassing "compiler build". There's unfortunately no way to learn about
just libtest and its dependencies (in a great and robust fashion) so to ensure
that we can copy the right artifacts over this commit introduces a new build
step, libtest.
The new libtest build step has documentation, dist, and link steps as std/rustc
already do. The compiler now depends on libtest instead of libstd, and all
compiler crates can now assume that test and its dependencies are implicitly
part of the sysroot (hence explicit dependencies being removed). This makes the
build a tad less parallel as in theory many rustc crates can be compiled in
parallel with libtest, but this likely isn't where we really need parallelism
either (all the time is still spent in the compiler).
All in all this allows the `dist-std` step to depend on both libstd and libtest,
so `rust-std` packages produced by rustbuild should start having both the
standard library and libtest.
Closes #32523
|
|
The facet of a stage is rarely relevant when running a tool or building
something, it's all a question of what stage the *compiler* is built in. We've
already got a nice handy `Compiler` structure to carry this information, so
let's use it!
This refactors the signature of the `Build::cargo` function two ways:
1. The `stage` argument is removed, this was just duplicated with the `compiler`
argument's stage field.
2. The `target` argument is now required. This was a bug where if the `--target`
flag isn't passed then the snapshot stage0 compiler is always used, so we
won't pick up any changes.
Much of the other changes in this commit are just propagating these decisions
outwards. For example many of the `Step` variants no longer have a stage
argument as they're baked into the compiler.
|
|
Just always build stage1 rustdoc, it's really not that much more to build as
it's essentially just one library.
|
|
The stage0 rustdoc comes from the snapshot, and we need a shim like with `rustc`
to pass `--cfg` for now.
|
|
Instead of using a `is_std: bool`, instead use a more well-typed and
self-documenting enum to indicate the mode in which Cargo is being invoked.
|
|
We've actually got quite a few tools that are compiled as part of our build,
let's start housing them all in a `tools` directory.
|
|
- make sure we copy the third party objects (crt*.o) to the target stage directory.
- apply the x86_64-musl logic also to the i686-musl target.
|
|
When cross compiling for a new host, we can't actually run the host compiler to
generate its own libs. In theory, however, all stage2 compilers (for any host)
will produce the same libraries, so we just require the build compiler to
produce the necessary host libraries and then we link those into place.
|
|
Right now it's implicitly done as part of building the compiler, but this was
intended to be a standalone step to ensure we tracked what built what.
|
|
Currently all multi-host builds assume the the build platform can run the
`llvm-config` binary generated for each host platform we're creating a compiler
for. Unfortunately this assumption isn't always true when cross compiling, so we
need to handle this case.
This commit alters the build script of `rustc_llvm` to understand when it's
running an `llvm-config` which is different than the platform we're targeting for.
|
|
During the transition period where we're still using ./configure and makefiles,
read some extra configuration from `config.mk` if it's present. This means that
the bootstrap build should be configured the same as the original ./configure
invocation.
Eventually this will all be removed in favor of only storing information in
`config.toml` (e.g. the configure script will generate config.toml), but for now
this should suffice.
|
|
This commit is the start of a series of commits which start to replace the
makefiles with a Cargo-based build system. The aim is not to remove the
makefiles entirely just yet but rather just replace the portions that invoke the
compiler to do the bootstrap. This commit specifically adds enough support to
perform the bootstrap (and all the cross compilation within) along with
generating documentation.
More commits will follow up in this series to actually wire up the makefiles to
call this build system, so stay tuned!
|
