| Age | Commit message (Collapse) | Author | Lines |
|---|
|
In #37280 we enabled line number debugging information in release artifacts,
primarily to close out #36452 where debugging information was critical for MSVC
builds of Rust to be useful in production. This commit, however, apparently had
some unfortunate side effects.
Namely it was noticed in #37477 that if `RUST_BACKTRACE=1` was set then any
compiler error would take a very long time for the compiler to exit. The cause
of the problem here was somewhat deep:
* For all compiler errors, the compiler will `panic!` with a known value. This
tears down the main compiler thread and allows cleaning up all the various
resources. By default, however, this panic output is suppressed for "normal"
compiler errors.
* When `RUST_BACKTRACE=1` was set this caused every compiler error to generate a
backtrace.
* The libbacktrace library hits a pathological case where it spends a very long
time in its custom allocation function, `backtrace_alloc`, because the
compiler has so much debugging information. More information about this can be
found in #29293 with a summary at the end of #37477.
To solve this problem this commit simply removes debuginfo from the compiler but
not from the standard library. This should allow us to keep #36452 closed while
also closing #37477. I've measured the difference to be orders of magnitude
faster than it was before, so we should see a much quicker time-to-exit after a
compile error when `RUST_BACKTRACE=1` is set.
Closes #37477
Closes #37571
|
|
This commit adds support for sccache, a ccache-like compiler which works on MSVC
and stores results into an S3 bucket. This also switches over all Travis and
AppVeyor automation to using sccache to ensure a shared and unified cache over
time which can be shared across builders.
The support for sccache manifests as a new `--enable-sccache` option which
instructs us to configure LLVM differently to use a 'sccache' binary instead of
a 'ccache' binary. All docker images for Travis builds are updated to download
Mozilla's tooltool builds of sccache onto various containers and systems.
Additionally a new `rust-lang-ci-sccache` bucket is configured to hold all of
our ccache goodies.
|
|
rustbuild: allow dynamically linking LLVM
The makefiles and `mklldeps.py` called `llvm-config --shared-mode` to
find out if LLVM defaulted to shared or static libraries, and just went
with that. But under rustbuild, `librustc_llvm/build.rs` was assuming
that LLVM should be static, and even forcing `--link-static` for 3.9+.
Now that build script also uses `--shared-mode` to learn the default,
which should work better for pre-3.9 configured for dynamic linking, as
it wasn't possible back then to choose differently via `llvm-config`.
Further, the configure script now has a new `--enable-llvm-link-shared`
option, which allows one to manually override `--link-shared` on 3.9+
instead of forcing static.
Update: There are now four static/shared scenarios that can happen
for the supported LLVM versions:
- 3.9+: By default use `llvm-config --link-static`
- 3.9+ and `--enable-llvm-link-shared`: Use `--link-shared` instead.
- 3.8: Use `llvm-config --shared-mode` and go with its answer.
- 3.7: Just assume static, maintaining the status quo.
|
|
rustbuild: Allow configuration of python interpreter
Add a configuration key to `config.toml`, read it from `./configure`, and add
auto-detection if none of those were specified.
Closes #35760
|
|
The makefiles and `mklldeps.py` called `llvm-config --shared-mode` to
find out if LLVM defaulted to shared or static libraries, and just went
with that. But under rustbuild, `librustc_llvm/build.rs` was assuming
that LLVM should be static, and even forcing `--link-static` for 3.9+.
Now that build script also uses `--shared-mode` to learn the default,
which should work better for pre-3.9 configured for dynamic linking, as
it wasn't possible back then to choose differently via `llvm-config`.
Further, the configure script now has a new `--enable-llvm-link-shared`
option, which allows one to manually override `--link-shared` on 3.9+
instead of forcing static.
|
|
Add a configuration key to `config.toml`, read it from `./configure`, and add
auto-detection if none of those were specified.
Closes #35760
|
|
|
|
update_with_config_mk() needs to read the new llvm debuginfo config
option from config.mk. Other than that, rustbuild already supports
LLVM's RelWithDebInfo build type.
|
|
compile-test: allow overriding nodejs binary location
Add a command-line argument to manually specify which nodejs binary should be used,
which disables the default search.
Original work done by @tari.
Fixes #34188.
|
|
Allow passing a custom nodejs directory in configure.
|
|
|
|
A few changes are included here:
* The `winapi` and `url` dependencies were dropped. The source code for these
projects is pretty weighty, and we're about to vendor them, so let's not
commit to that intake just yet. If necessary we can vendor them later but for
now it shouldn't be necessary.
* The `--frozen` flag is now always passed to Cargo, obviating the need for
tidy's `cargo_lock` check.
* Tidy was updated to not check the vendor directory
Closes #34687
|
|
|
|
|
|
|
|
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/36788.
|
|
This commit enables by default passing the `-C debuginfo=1` argument to the
compiler for the stable, beta, and nightly release channels. A new configure
option was also added, `--enable-debuginfo-lines`, to enable this behavior in
developer builds as well.
Closes #36452
|
|
We hope to move to AppVeyor in the near future off of Buildbot + EC2. This adds
an `appveyor.yml` configuration file which is ready to run builds on the auto
branch. This is also accompanied with a few minor fixes to the build system and
such to accomodate AppVeyor.
The intention is that we're not switching over to AppVeyor entirely just yet,
but rather we'll watch the builds for a week or so. If everything checks out
then we'll start gating on AppVeyor instead of Buildbot!
|
|
configure: Add options for separate musl roots
This allows using the `./configure` script to enable rustbuild to compile
multiple musl targets at once. We'll hopefully use this soon on our bots to
produce a bunch of targets.
|
|
rustbuild: Add install target. #34675
It just prints to the screen currently.
r? @alexcrichton
I'm working on the next commit to actually have it install.
|
|
|
|
This allows using the `./configure` script to enable rustbuild to compile
multiple musl targets at once. We'll hopefully use this soon on our bots to
produce a bunch of targets.
|
|
In #36292, support was added to target musl libc for ARM targets using
rustbuild. Specifically, that change allowed the addition of per-target
"musl-root" options in the rustbuild config.toml so that multiple
targets depending on musl could be built. However, that implementation
contained a couple of omissions: the musl-root option was added to the
config, but was never added to the TOML parsing, and therefore was not
actually being loaded from config.toml. This commit rectifies that and
allows successful building of musl-based ARM targets.
|
|
This avoids issues with mingw path conversions.
|
|
r=alexcrichton
adding a check to bootstrap script
and a check to the rust config script
refs #36207
first crack at making configure detect nodejs
|
|
rustbuild: per target musl-root
config.toml now accepts a target.$TARGET.musl-root key that lets you
override the "build" musl-root value, which is set via the --musl-root
flag or via the build.musl-root key.
With this change, it's now possible to compile std for several musl
targets at once. Here's are the sample commands to do such thing:
```
$ configure \
--enable-rustbuild \
--target=x86_64-unknown-linux-musl,arm-unknown-linux-musleabi \
--musl-root=/musl/x86_64-unknown-linux-musl/
$ edit config.toml && tail config.toml
[target.arm-unknown-linux-musleabi]
musl-root = "/x-tools/arm-unknown-linux-musleabi/arm-unknown-linux-musleabi/sysroot/usr"
$ make
```
r? @alexcrichton
With this we should be able to start producing releases of std for arm musl targets
|
|
a nodejs cmd sanity check
|
|
|
|
config.toml now accepts a target.$TARGET.musl-root key that lets you
override the "build" musl-root value, which is set via the --musl-root
flag or via the build.musl-root key.
With this change, it's now possible to compile std for several musl
targets at once. Here's are the sample commands to do such thing:
```
$ configure \
--enable-rustbuild \
--target=x86_64-unknown-linux-musl,arm-unknown-linux-musleabi \
--musl-root=/musl/x86_64-unknown-linux-musl/
$ edit config.toml && tail config.toml
[target.arm-unknown-linux-musleabi]
musl-root = "/x-tools/arm-unknown-linux-musleabi/arm-unknown-linux-musleabi/sysroot/usr"
$ make
```
|
|
and a check to the rust config script
|
|
|
|
to match the behavior of the old Makefile-based build system
closes #35752
|
|
but keep them enabled by default to maintain the status quo.
When disabled shaves ~56KB off every x86_64-unknown-linux-gnu
binary.
To disable backtraces you have to use a config.toml (see
src/bootstrap/config.toml.example for details) when building rustc/std:
$ python bootstrap.py --config=config.toml
|
|
The Ninja generator generally builds much faster than make. It may also
be used on Windows to have a vast speed improvement over the Visual
Studio generators.
Currently hidden behind an `--enable-ninja` flag because it does not
obey the top-level `-j` or `-l` flags given to `make`.
|
|
The organization in rustbuild was a little odd at the moment where the `lib.rs`
was quite small but the binary `main.rs` was much larger. Unfortunately as well
there was a `build/` directory with the implementation of the build system, but
this directory was ignored by GitHub on the file-search prompt which was a
little annoying.
This commit reorganizes rustbuild slightly where all the library files (the
build system) is located directly inside of `src/bootstrap` and all the binaries
now live in `src/bootstrap/bin` (they're small). Hopefully this should allow
GitHub to index and allow navigating all the files while maintaining a
relatively similar layout to the other libraries in `src/`.
|
