mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
b0440d359b
rust/src/stage0.txt

38 lines
1.7 KiB
Plaintext
Raw Normal View History

mk: Bootstrap from stable instead of snapshots 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-13 13:18:35 -05:00
# This file describes the stage0 compiler that's used to then bootstrap the Rust
# compiler itself. For the rustbuild build system, this also describes the
# relevant Cargo revision that we're using.
#
stage0.txt: typo fix
2016-12-17 20:12:18 -06:00
# Currently Rust always bootstraps from the previous stable release, and in our
mk: Bootstrap from stable instead of snapshots 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-13 13:18:35 -05:00
# train model this means that the master branch bootstraps from beta, beta
# bootstraps from current stable, and stable bootstraps from the previous stable
# release.
#
# If you're looking at this file on the master branch, you'll likely see that
Update stage0 bootstrap compiler We've got a freshly minted beta compiler, let's update to use that on nightly! This has a few other changes associated with it as well * A bump to the rustc version number (to 1.19.0) * Movement of the `cargo` and `rls` submodules to their "proper" location in `src/tools/{cargo,rls}`. Now that Cargo workspaces support the `exclude` option this can work. * Updates of the `cargo` and `rls` submodules to their master branches. * Tweak to the `src/stage0.txt` format to be more amenable for Cargo version numbers. On the beta channel Cargo will bootstrap from a different version than rustc (e.g. the version numbers are different), so we need different configuration for this. * Addition of `dev` as a readable key in the `src/stage0.txt` format. If present then stage0 compilers are downloaded from `dev-static.rust-lang.org` instead of `static.rust-lang.org`. This is added to accomodate our updated release process with Travis and AppVeyor.
2017-04-20 16:32:54 -05:00
# rustc and cargo are configured to `beta`, whereas if you're looking at a
# source tarball for a stable release you'll likely see `1.x.0` for rustc and
# `0.x.0` for Cargo where they were released on `date`.
mk: Bootstrap from stable instead of snapshots 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-13 13:18:35 -05:00
Switch to 1.26 bootstrap compiler
2018-05-10 13:02:19 -05:00
date: 2018-05-10
Bump to 1.22.0
2017-08-28 10:55:45 -05:00
rustc: beta
cargo: beta
Update stage0 bootstrap compiler We've got a freshly minted beta compiler, let's update to use that on nightly! This has a few other changes associated with it as well * A bump to the rustc version number (to 1.19.0) * Movement of the `cargo` and `rls` submodules to their "proper" location in `src/tools/{cargo,rls}`. Now that Cargo workspaces support the `exclude` option this can work. * Updates of the `cargo` and `rls` submodules to their master branches. * Tweak to the `src/stage0.txt` format to be more amenable for Cargo version numbers. On the beta channel Cargo will bootstrap from a different version than rustc (e.g. the version numbers are different), so we need different configuration for this. * Addition of `dev` as a readable key in the `src/stage0.txt` format. If present then stage0 compilers are downloaded from `dev-static.rust-lang.org` instead of `static.rust-lang.org`. This is added to accomodate our updated release process with Travis and AppVeyor.
2017-04-20 16:32:54 -05:00
# When making a stable release the process currently looks like:
#
# 1. Produce stable build, upload it to dev-static
# 2. Produce a beta build from the previous stable build, upload to static
# 3. Produce a nightly build from previous beta, upload to static
# 4. Upload stable build to static, publish full release
#
# This means that there's a small window of time (a few days) where artifacts
# are downloaded from dev-static.rust-lang.org instead of static.rust-lang.org.
# In order to ease this transition we have an extra key is in this configuration
# file below. When uncommented this will instruct the bootstrap.py script to
# download from dev-static.rust-lang.org.
#
# This key is typically commented out at all times. If you're looking at a
# stable release tarball it should *definitely* be commented out. If you're
# looking at a beta source tarball and it's uncommented we'll shortly comment it
# out.
#dev: 1
Reference in New Issue Copy Permalink