| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fail ./x.py on invalid command
Make the ./x.py script fail when run with an invalid command, like:
```
./x.py nonsense
```
This helps in case of chaining multiple runs, eg.:
```
./x.py biuld && ./x.py test
```
|
|
bootstrap: remove unneeded extern crate
The crate itself is internally referenced by serde_derive.
|
|
include Cargo.{toml,lock} in rust-src tarball
The lock file is interesting because e.g. xargo could use it to build libstd against the same dependencies that were used for the main build. More generally speaking, just documenting in this form which exact dependencies should be used IMHO makes lots of sense.
I added the Cargo.toml mostly because having the lock without the toml feels odd. Of course, the toml contains references to paths that don't actually exist in the rust-src tarball. Not sure if that is considered a problem.
|
|
All architectures use the same errors, no need to cross-compile a version only
to not look at it.
|
|
by the end, use the channel to determine its value
|
|
No need to depend on librustc! All we need is libstd
Closes #44140
|
|
When we pass `--host` the `self.hosts` array doesn't contain `self.build`, so
check `self.build` to see if we can uplift.
|
|
OpenSSL's Configure script is missing a shebang. On some platforms,
execve falls back to execution with the shell. Some other platforms,
like musl, will fail with an exec format error. Avoid this by calling
perl explicitly (since it's a perl script).
|
|
rustbuild: Rewrite the configure script in Python
This commit rewrites our ancient `./configure` script from shell into Python.
The impetus for this change is to remove `config.mk` which is just a vestige of
the old makefile build system at this point. Instead all configuration is now
solely done through `config.toml`.
The python script allows us to more flexibly program (aka we can use loops
easily) and create a `config.toml` which is based off `config.toml.example`.
This way we can preserve comments and munge various values as we see fit.
It is intended that the configure script here is a drop-in replacement for the
previous configure script, no functional change is intended. Also note that the
rationale for this is also because our build system requires Python, so having a
python script a bit earlier shouldn't cause too many problems.
Closes #40730
Closes #43295
Closes #42255
Closes #38058
Closes #32176
|
|
The crate itself is internally referenced by serde_derive.
|
|
This commit rewrites our ancient `./configure` script from shell into Python.
The impetus for this change is to remove `config.mk` which is just a vestige of
the old makefile build system at this point. Instead all configuration is now
solely done through `config.toml`.
The python script allows us to more flexibly program (aka we can use loops
easily) and create a `config.toml` which is based off `config.toml.example`.
This way we can preserve comments and munge various values as we see fit.
It is intended that the configure script here is a drop-in replacement for the
previous configure script, no functional change is intended. Also note that the
rationale for this is also because our build system requires Python, so having a
python script a bit earlier shouldn't cause too many problems.
Closes #40730
|
|
Make the ./x.py script fail when run with an invalid command, like:
./x.py nonsense
This helps in case of chaining multiple runs, eg.:
./x.py biuld && ./x.py test
|
|
distcheck complains that this file references projects not cotnained in the tarball
|
|
Discovered in #43767 it turns out the default MSBuild generator in CMake for
whatever reason isn't supporting many of the configuration options we give to
LLVM. To improve the contributor experience automatically enable Ninja if we
find it to ensure that "flavorful" configurations of LLVM work by default in
more situations.
Closes #43767
|
|
|
|
|
|
This avoids the possibility of a duplicate or conflicting crt-static
command line option sent to rustc.
|
|
This controls the value of the crt-static feature used when building the
standard library for a target, as well as the compiler itself when that
target is the host.
|
|
They are required for linking it, even though it is a library, because
crtn.o in post_link_objects, as hardcoded in src/librustc_back/target/
linux_musl_base.rs, is added to the linker command line for both
executables and libraries.
|
|
|
|
|
|
|
|
Implement a temp redirect for cargo docs
As discussed in
https://github.com/rust-lang/cargo/issues/4040#issuecomment-321639074
This is a redirect meant to be replaced once cargo docs have been
converted to mdbook. We just want *a* URL to ride the trains for now so
that we can print doc.rust-lang.org/cargo in the paper book and
guarantee that it will go *somewhere* useful by the time the book is
printed.
Implemented as a meta redirect in HTML because we don't currently have
any google juice at doc.rust-lang.org/cargo to lose.
When I run `./x.py doc`, this creates a `build/x86_64-apple-darwin/doc/cargo/index.html` file that contains a meta redirect to doc.crates.io. As I understand rust-central-station to work, this should be what we need to make `doc.rust-lang.org/cargo` to work.
r? @alexcrichton and/or @steveklabnik
|
|
Fix typos & us spellings
Fixing some typos and non en-US spellings.
(Update of PR https://github.com/rust-lang/rust/pull/42812 )
|
|
As discussed in
https://github.com/rust-lang/cargo/issues/4040#issuecomment-321639074
This is a redirect meant to be replaced once cargo docs have been
converted to mdbook. We just want *a* URL to ride the trains for now so
that we can print doc.rust-lang.org/cargo in the paper book and
guarantee that it will go *somewhere* useful by the time the book is
printed.
Implemented as a meta redirect in HTML because we don't currently have
any google juice at doc.rust-lang.org/cargo to lose.
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|
|
|
|
Ship the rustdoc book
Fixes #42322, as it's the last step.
Blocked on https://github.com/rust-lang/rust/pull/43790, though they will not conflict.
r? @rust-lang/docs
|
|
|
|
Cleanup for "Support compiling rustc without LLVM (try 2)"
This includes a small patch to allow running tests without llvm. Also check if you are not trying to compile a dylib.
cc #42932
r? @alexcrichton
|
|
|
|
|
|
Fix some typos
Follow up of #43794
If refined my script a little bit and found some more.
|
|
|
|
|
|
|
|
This fixes the bug we previously had where we'd build a libtest tool
after building a libstd tool and clear out the libstd tool. Since we
clear out all tools for a given stage on invocations of CleanTools after
lib{std, test, rustc} change, we need to make sure that all tools built
with that stage will be built after the clearing is done.
The fix contained here technically isn't perfect; there is still an edge
case of compiling a libstd tool, then compiling libtest, which will
clear out the libstd tool and it won't ever get rebuilt within that
session of rustbuild. This is where the caching system used today shows
it's problems -- in effect, all tools depend on a global counter of the
stage being cleared out. We can implement such a counter in a future
patch to ensure that tools are rebuilt as needed, but it is deemed
unlikely that it will be required in practice, since most if not all
tools are built after the relevant stage's std/test/rustc are built,
though this is only an opinion and hasn't been verified.
|
|
|
|
This permits proc macro crates to correctly work with rustdoc.
|
|
|
|
Some users of the build system change the git sha on every build due to
utilizing git to push changes to a remote server. This allows them to
simply configure that away instead of depending on custom patches to
rustbuild.
|
|
We first check the configuration, then passed parameters (--build), then
fall back to the auto-detection that bootstrap.py does.
Fixes #39673.
|
|
We no longer care about the source of this information, so there is no
reason to restrict users.
|
|
This introduces a slight change in behavior, where we unilaterally
respect the --host and --target parameters passed for all sanity
checking and runtime configuration.
|
|
|
|
It's way more discoverable here.
|
|
|
|
suggestion from Mark-Simulacrum
|
|
Link LLVM tools dynamically
Set `LLVM_LINK_LLVM_DYLIB=ON` -- "If enabled, tools will be linked with
the libLLVM shared library." Rust doesn't ship any of the LLVM tools,
and only needs a few at all for some test cases, so statically linking
the tools is just a waste of space. I've also had memory issues on
slower machines with LLVM debuginfo enabled, when several tools start
linking in parallel consuming several GBs each.
With the default configuration, `build/x86_64-unknown-linux-gnu/llvm`
was 1.5GB before, now down to 731MB. The difference is more drastic
with `--enable-llvm-release-debuginfo`, from 28GB to "only" 13GB.
This does not change the linking behavior of `rustc_llvm`.
|
