| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Add additional instructions when `sudo ./x.py install` fails to
complete the build.
This resolves issues #40108 and #49269.
|
|
Point contributors to the rustc-guide...
|
|
Since the bootstrap does it now
|
|
Because it, obviously, changes all the time and 600MiB is way
out-of-date now.
|
|
|
|
|
|
Making it consistent across the board, as most of them already use `$`.
Also split one continues bash run into two, to make it easier see
different runs: one with warning and another with error.
|
|
|
|
|
|
Corrected the grammar of the document.
|
|
|
|
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The old wording made me think you were supposed to do `python x.py --build=msvc`, which is not the case. Specify that you need to use the target triple.
|
|
It's way more discoverable here.
|
|
|
|
|
|
only create source tarball for the Dist subcommand
mark install rule as default for Kind::Install
split install-docs
split install-std
factor out empty_dir handling
split install-cargo
split install-analysis
split install-src
rework install-rustc
properly handle cross-compilation setups for install
use pkgname in install
split plain source tarball generation from rust-src dist
document src-tarball in config.toml.exmaple
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
I just updated a few links to use https instead of http.
Thank you! ^ _ ^
|
|
|
|
|
|
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/36115.
|
|
This commit switches the default build system for Rust from the makefiles to
rustbuild. The rustbuild build system has been in development for almost a year
now and has become quite mature over time. This commit is an implementation of
the proposal on [internals] which slates deletion of the makefiles on
2016-01-02.
[internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368
This commit also updates various documentation in `README.md`,
`CONTRIBUTING.md`, `src/bootstrap/README.md`, and throughout the source code of
rustbuild itself.
Closes #37858
|
|
This commit is a rewrite of the user-facing interface to the rustbuild build
system. The intention here is to make it much easier to compile/test the project
without having to remember weird rule names and such. An overall view of the new
interface is:
# build everything
./x.py build
# document everyting
./x.py doc
# test everything
./x.py test
# test libstd
./x.py test src/libstd
# build libcore stage0
./x.py build src/libcore --stage 0
# run stage1 run-pass tests
./x.py test src/test/run-pass --stage 1
The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py`
script. This `x` was chosen to be both short and easily tab-completable (no
collisions in that namespace!). The build system now accepts a "subcommand" of
what to do next, the main ones being build/doc/test.
Each subcommand then receives an optional list of arguments. These arguments are
paths in the source repo of what to work with. That is, if you want to test a
directory, you just pass that directory as an argument.
The purpose of this rewrite is to do away with all of the arcane renames like
"rpass" is the "run-pass" suite, "cfail" is the "compile-fail" suite, etc. By
simply working with directories and files it's much more intuitive of how to run
a test (just pass it as an argument).
The rustbuild step/dependency management was also rewritten along the way to
make this easy to work with and define, but that's largely just a refactoring of
what was there before.
The *intention* is that this support is extended for arbitrary files (e.g.
`src/test/run-pass/my-test-case.rs`), but that isn't quite implemented just yet.
Instead directories work for now but we can follow up with stricter path
filtering logic to plumb through all the arguments.
|
|
|
|
|
|
The minimum got bumped in the LLVM upgrade of #34743.
|
|
The invocation of vcvars is only needed for versions of Visual Studio that
rustbuild or cmake doesn't understand, but if older versions are installed then
there's no need to call vcvars.
Closes #34576
|
|
Instructions on how to build Rust with rustbuild
This is a much simpler option for those on Windows who use msvc.
|
|
This is a much simpler option for those on Windows who use msvc.
Signed-off-by: Peter Atashian <retep998@gmail.com>
|
|
Rollup of 7 pull requests
- Successful merges: #34531, #34545, #34551, #34566, #34567, #34574, #34583
- Failed merges:
|
|
The ./configure command in README.md's Building Documentation section was
missing the $ prefix. Add the prefix to be consistent with other commands in the
document.
|
|
The LLVM build system is somewhat picky about which Python is used to build it
as it's known to be incompatible with the default `python2` package that ships
with MinGW. This was previously detected for MSVC builds but the logic was left
out for MinGW by accident (now that we've switched to cmake builds for LLVM
everywhere).
This corrects the `./configure` check and also updates the `README.md`
accordingly. Additionally, a number of instructions were updated to work with
the most recent copy of MSYS2.
Closes #34489
|
|
|
|
fix indentation in README
|
|
|
|
One of the newest versions of MSYS2 now only has one .cmd file which replaces the old bat files. It has to be used to launch the mingw32/64 shell.
|
|
G++ 4.7 is the minimum requirement, but later versions are also okay.
|
|
getting-started
|
|
http://mingw-w64.org/doku.php/download/mingw-builds now provides GCC 5.x as a default version, but avoiding 5.x is exactly the reason why Mingw-builds is recommended instead of MSYS2's own mingw toolchain. One of the 4.9.x versions has to manually chosen during installation.
|
|
Using spaces in the install path causes the issue in #31293.
|
