about summary refs log tree commit diff
path: root/src/bootstrap/bootstrap.py
AgeCommit message (Collapse)AuthorLines
2016-05-08Remove sha256 file only if present.Cyryl Płotnicki-Chudyk-5/+8
2016-05-08Better error handling for bootstrap file downloads.Cyryl Płotnicki-Chudyk-14/+20
Remove the temp files if something goes wrong.
2016-04-30Code cleanup in download() in bootstrap.pyCyryl Płotnicki-Chudyk-12/+12
Make download() receive less parameters and use it explicitly 2 times in get().
2016-04-30Get a file during bootstrap to a temp location.Cyryl Płotnicki-Chudyk-5/+23
When downloading a file in the bootstrap phase - get it to a temp location first. Verify it there and only if downloaded properly move it to the `cache` directory. This should prevent `make` being stuck if the download was interrupted or otherwise corrupted. The temporary files are deleted in case of an exception.
2016-04-19mk: Bootstrap from stable instead of snapshotsAlex Crichton-67/+84
This commit removes all infrastructure from the repository for our so-called snapshots to instead bootstrap the compiler from stable releases. Bootstrapping from a previously stable release is a long-desired feature of distros because they're not fans of downloading binary stage0 blobs from us. Additionally, this makes our own CI easier as we can decommission all of the snapshot builders and start having a regular cadence to when we update the stage0 compiler. A new `src/etc/get-stage0.py` script was added which shares some code with `src/bootstrap/bootstrap.py` to read a new file, `src/stage0.txt`, which lists the current stage0 compiler as well as cargo that we bootstrap from. This script will download the relevant `rustc` package an unpack it into `$target/stage0` as we do today. One problem of bootstrapping from stable releases is that we're not able to compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd). To overcome this we employ two strategies: * The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt` (enabled as a result of #32731) and exported by the build system. This enables nightly features in the compiler we download. * The standard library and compiler are pinned to a specific stage0, which doesn't change, so we're guaranteed that we'll continue compiling as we start from a known fixed source. The process for making a release will also need to be tweaked now to continue to cadence of bootstrapping from the previous release. This process looks like: 1. Merge `beta` to `stable` 2. Produce a new stable compiler. 3. Change `master` to bootstrap from this new stable compiler. 4. Merge `master` to `beta` 5. Produce a new beta compiler 6. Change `master` to bootstrap from this new beta compiler. Step 3 above should involve very few changes as `master` was previously bootstrapping from `beta` which is the same as `stable` at that point in time. Step 6, however, is where we benefit from removing lots of `#[cfg(stage0)]` and get to use new features. This also shouldn't slow the release too much as steps 1-5 requires little work other than waiting and step 6 just needs to happen at some point during a release cycle, it's not time sensitive. Closes #29555 Closes #29557
2016-04-18rustbuild: Add support for compiletest test suitesAlex Crichton-1/+1
This commit adds support in rustbuild for running all of the compiletest test suites as part of `make check`. The `compiletest` program was moved to `src/tools` (like `rustbook` and others) and is now just compiled like any other old tool. Each test suite has a pretty standard set of dependencies and just tweaks various parameters to the final compiletest executable. Note that full support is lacking in terms of: * Once a test suite has passed, that's not remembered. When a test suite is requested to be run, it's always run. * The arguments to compiletest probably don't work for every possible combination of platforms and testing environments just yet. There will likely need to be future updates to tweak various pieces here and there. * Cross compiled test suites probably don't work just yet, support for that will come in a follow-up patch.
2016-04-13rustbuild: Verify sha256 of downloaded tarballsNick Platt-7/+24
2016-04-13rustbuild: Improve error messaging in bootstrap.pyNick Platt-6/+16
For normal invocations, print a short error message and exit. When the verbose option is enabled, also print the backtrace.
2016-03-01rustbuild: Fix building from an empty directoryAlex Crichton-1/+2
A stray shutil.rmtree happened when it shouldn't have happened, causing the entire build to fail.
2016-02-28rustbuild: Update nightly dateAlex Crichton-0/+1
Also fix a bug where we didn't clean out previous nightlies
2016-02-11bootstrap: Read configuration from config.mkAlex Crichton-0/+16
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.
2016-02-11Add a Cargo-based build systemAlex Crichton-0/+300
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!