---

yaml
---
r: 277806
b: refs/heads/try
c: cf8a1b0
h: refs/heads/master

Author: Manishearth

[refs]

@@ -1,7 +1,7 @@
 ---
 refs/heads/master: 6dbb0e86aec11050480beb76eade6fb805010ba7
 refs/heads/snap-stage3: 235d77457d80b549dad3ac36d94f235208a1eafb
-refs/heads/try: 433f907050432af6396a317525f60579c604b3e0
+refs/heads/try: cf8a1b0998fb561e76acfe4b8269a4df5fb60bc8
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/try/Makefile.in

@@ -59,8 +59,9 @@
 #   * check-stage$(stage)-$(crate) - Test a crate in a specific stage
 #   * check-stage$(stage)-{rpass,rfail,cfail,rmake,...} - Run tests in src/test/
 #   * check-stage1-T-$(target)-H-$(host) - Run cross-compiled-tests
-#   * tidy - Basic style check, show highest rustc error code and
-#     the status of language and lib features
+#   * tidy-basic - show file / line stats
+#   * tidy-errors - show the highest rustc error code
+#   * tidy-features - show the status of language and lib features
 #   * rustc-stage$(stage) - Only build up to a specific stage
 #
 # Then mix in some of these environment variables to harness the

branches/try/configure

@@ -632,7 +632,6 @@ valopt build "${DEFAULT_BUILD}" "GNUs ./configure syntax LLVM build triple"
 valopt android-cross-path "" "Android NDK standalone path (deprecated)"
 valopt i686-linux-android-ndk "" "i686-linux-android NDK standalone path"
 valopt arm-linux-androideabi-ndk "" "arm-linux-androideabi NDK standalone path"
-valopt armv7-linux-androideabi-ndk "" "armv7-linux-androideabi NDK standalone path"
 valopt aarch64-linux-android-ndk "" "aarch64-linux-android NDK standalone path"
 valopt nacl-cross-path  "" "NaCl SDK path (Pepper Canary is recommended). Must be absolute!"
 valopt release-channel "dev" "the name of the release channel to build"
@@ -1145,15 +1144,6 @@ do
 
     case $i in
         *android*)
-            case $i in
-                armv7-linux-androideabi)
-                    cmd_prefix="arm-linux-androideabi"
-                    ;;
-                *)
-                    cmd_prefix=$i
-                    ;;
-            esac
-
             upper_snake_target=$(echo "$i" | tr '[:lower:]' '[:upper:]' | tr '\-' '\_')
             eval ndk=\$"CFG_${upper_snake_target}_NDK"
             if [ -z "$ndk" ]
@@ -1164,7 +1154,7 @@ do
             fi
 
             # Perform a basic sanity check of the NDK
-            for android_ndk_tool in "$ndk/bin/$cmd_prefix-gcc" "$ndk/bin/$cmd_prefix-g++" "$ndk/bin/$cmd_prefix-ar"
+            for android_ndk_tool in "$ndk/bin/$i-gcc" "$ndk/bin/$i-g++" "$ndk/bin/$i-ar"
             do
                 if [ ! -f $android_ndk_tool ]
                 then
@@ -1796,7 +1786,6 @@ putvar CFG_LIBDIR_RELATIVE
 putvar CFG_DISABLE_MANAGE_SUBMODULES
 putvar CFG_AARCH64_LINUX_ANDROID_NDK
 putvar CFG_ARM_LINUX_ANDROIDEABI_NDK
-putvar CFG_ARMV7_LINUX_ANDROIDEABI_NDK
 putvar CFG_I686_LINUX_ANDROID_NDK
 putvar CFG_NACL_CROSS_PATH
 putvar CFG_MANDIR

branches/try/mk/cfg/armv7-linux-androideabi.mk

@@ -1,4 +1,4 @@
-# rustbuild - Bootstrapping Rust
+# Bootstrapping Rust
 
 This is an in-progress README which is targeted at helping to explain how Rust
 is bootstrapped and in general some of the technical details of the build
@@ -8,64 +8,20 @@ system.
 > intended to be the primarily used one just yet. The makefiles are currently
 > the ones that are still "guaranteed to work" as much as possible at least.
 
-## Using rustbuild
+## Using the new build system
 
 When configuring Rust via `./configure`, pass the following to enable building
 via this build system:
 
 ```
 ./configure --enable-rustbuild
-make
 ```
 
-Afterwards the `Makefile` which is generated will have a few commands like
-`make check`, `make tidy`, etc. For finer-grained control, the
-`bootstrap.py` entry point can be used:
-
-```
-python src/bootstrap/bootstrap.py
-```
-
-This accepts a number of options like `--stage` and `--step` which can configure
-what's actually being done.
-
-## Configuring rustbuild
-
-There are currently two primary methods for configuring the rustbuild build
-system. First, the `./configure` options serialized in `config.mk` will be
-parsed and read. That is, if any `./configure` options are passed, they'll be
-handled naturally.
-
-Next, rustbuild offers a TOML-based configuration system with a `config.toml`
-file in the same location as `config.mk`. An example of this configuration can
-be found at `src/bootstrap/config.toml.example`, and the configuration file
-can also be passed as `--config path/to/config.toml` if the build system is
-being invoked manually (via the python script).
-
-## Build stages
-
-The rustbuild build system goes through a few phases to actually build the
-compiler. What actually happens when you invoke rustbuild is:
-
-1. The entry point script, `src/bootstrap/bootstrap.py` is run. This script is
-   responsible for downloading the stage0 compiler/Cargo binaries, and it then
-   compiles the build system itself (this folder). Finally, it then invokes the
-   actual `boostrap` binary build system.
-2. In Rust, `bootstrap` will slurp up all configuration, perform a number of
-   sanity checks (compilers exist for example), and then start building the
-   stage0 artifacts.
-3. The stage0 `cargo` downloaded earlier is used to build the standard library
-   and the compiler, and then these binaries are then copied to the `stage1`
-   directory. That compiler is then used to generate the stage1 artifacts which
-   are then copied to the stage2 directory, and then finally the stage2
-   artifacts are generated using that compiler.
-
-The goal of each stage is to (a) leverage Cargo as much as possible and failing
-that (b) leverage Rust as much as possible!
+## ...
 
 ## Directory Layout
 
-This build system houses all output under the `build` directory, which looks
+This build system houses all output under the `target` directory, which looks
 like this:
 
 ```
@@ -86,12 +42,6 @@ build/
     debug/
     release/
 
-  # Output of the dist-related steps like dist-std, dist-rustc, and dist-docs
-  dist/
-
-  # Temporary directory used for various input/output as part of various stages
-  tmp/
-
   # Each remaining directory is scoped by the "host" triple of compilation at
   # hand.
   x86_64-unknown-linux-gnu/
@@ -100,8 +50,7 @@ build/
     # folder is under. The exact layout here will likely depend on the platform,
     # and this is also built with CMake so the build system is also likely
     # different.
-    compiler-rt/
-      build/
+    compiler-rt/build/
 
     # Output folder for LLVM if it is compiled for this target
     llvm/
@@ -118,17 +67,6 @@ build/
       share/
       ...
 
-    # Output folder for all documentation of this target. This is what's filled
-    # in whenever the `doc` step is run.
-    doc/
-
-    # Output for all compiletest-based test suites
-    test/
-      run-pass/
-      compile-fail/
-      debuginfo/
-      ...
-
     # Location where the stage0 Cargo and Rust compiler are unpacked. This
     # directory is purely an extracted and overlaid tarball of these two (done
     # by the bootstrapy python script). In theory the build system does not
@@ -144,9 +82,7 @@ build/
     # invocation. The build system instruments calling Cargo in the right order
     # with the right variables to ensure these are filled in correctly.
     stageN-std/
-    stageN-test/
     stageN-rustc/
-    stageN-tools/
 
     # This is a special case of the above directories, **not** filled in via
     # Cargo but rather the build system itself. The stage0 compiler already has
@@ -160,7 +96,7 @@ build/
     # Basically this directory is just a temporary artifact use to configure the
     # stage0 compiler to ensure that the libstd we just built is used to
     # compile the stage1 compiler.
-    stage0-sysroot/lib/
+    stage0-rustc/lib/
 
     # These output directories are intended to be standalone working
     # implementations of the compiler (corresponding to each stage). The build
@@ -172,69 +108,3 @@ build/
     stage2/
     stage3/
 ```
-
-## Cargo projects
-
-The current build is unfortunately not quite as simple as `cargo build` in a
-directory, but rather the compiler is split into three different Cargo projects:
-
-* `src/rustc/std_shim` - a project which builds and compiles libstd
-* `src/rustc/test_shim` - a project which builds and compiles libtest
-* `src/rustc` - the actual compiler itself
-
-Each "project" has a corresponding Cargo.lock file with all dependencies, and
-this means that building the compiler involves running Cargo three times. The
-structure here serves two goals:
-
-1. Facilitating dependencies coming from crates.io. These dependencies don't
-   depend on `std`, so libstd is a separate project compiled ahead of time
-   before the actual compiler builds.
-2. Splitting "host artifacts" from "target artifacts". That is, when building
-   code for an arbitrary target you don't need the entire compiler, but you'll
-   end up needing libraries like libtest that depend on std but also want to use
-   crates.io dependencies. Hence, libtest is split out as its own project that
-   is sequenced after `std` but before `rustc`. This project is built for all
-   targets.
-
-There is some loss in build parallelism here because libtest can be compiled in
-parallel with a number of rustc artifacts, but in theory the loss isn't too bad!
-
-## Build tools
-
-We've actually got quite a few tools that we use in the compiler's build system
-and for testing. To organize these, each tool is a project in `src/tools` with a
-corresponding `Cargo.toml`. All tools are compiled with Cargo (currently having
-independent `Cargo.lock` files) and do not currently explicitly depend on the
-compiler or standard library. Compiling each tool is sequenced after the
-appropriate libstd/libtest/librustc compile above.
-
-## Extending rustbuild
-
-So you'd like to add a feature to the rustbuild build system or just fix a bug.
-Great! One of the major motivational factors for moving away from `make` is that
-Rust is in theory much easier to read, modify, and write. If you find anything
-excessively confusing, please open an issue on this and we'll try to get it
-documented or simplified pronto.
-
-First up, you'll probably want to read over the documentation above as that'll
-give you a high level overview of what rustbuild is doing. You also probably
-want to play around a bit yourself by just getting it up and running before you
-dive too much into the actual build system itself.
-
-After that, each module in rustbuild should have enough documentation to keep
-you up and running. Some general areas that you may be interested in modifying
-are:
-
-* Adding a new build tool? Take a look at `build/step.rs` for examples of other
-  tools, as well as `build/mod.rs`.
-* Adding a new compiler crate? Look no further! Adding crates can be done by
-  adding a new directory with `Cargo.toml` followed by configuring all
-  `Cargo.toml` files accordingly.
-* Adding a new dependency from crates.io? We're still working on that, so hold
-  off on that for now.
-* Adding a new configuration option? Take a look at `build/config.rs` or perhaps
-  `build/flags.rs` and then modify the build elsewhere to read that option.
-* Adding a sanity check? Take a look at `build/sanity.rs`.
-
-If you have any questions feel free to reach out on `#rust-internals` on IRC or
-open an issue in the bug tracker!

branches/try/src/bootstrap/README.md

@@ -16,46 +16,20 @@
 import subprocess
 import sys
 import tarfile
-import tempfile
-
 
 def get(url, path, verbose=False):
+    print("downloading " + url)
     sha_url = url + ".sha256"
-    with tempfile.NamedTemporaryFile(delete=False) as temp_file:
-        temp_path = temp_file.name
-    with tempfile.NamedTemporaryFile(suffix=".sha256", delete=False) as sha_file:
-        sha_path = sha_file.name
-
-    try:
-        download(sha_path, sha_url, verbose)
-        download(temp_path, url, verbose)
-        verify(temp_path, sha_path, verbose)
-        print("moving " + temp_path + " to " + path)
-        shutil.move(temp_path, path)
-    finally:
-        delete_if_present(sha_path)
-        delete_if_present(temp_path)
-
-
-def delete_if_present(path):
-    if os.path.isfile(path):
-        print("removing " + path)
-        os.unlink(path)
-
-
-def download(path, url, verbose):
-    print("downloading " + url + " to " + path)
-    # see http://serverfault.com/questions/301128/how-to-download
-    if sys.platform == 'win32':
-        run(["PowerShell.exe", "/nologo", "-Command",
-             "(New-Object System.Net.WebClient)"
-             ".DownloadFile('{}', '{}')".format(url, path)],
-            verbose=verbose)
-    else:
-        run(["curl", "-o", path, url], verbose=verbose)
-
-
-def verify(path, sha_path, verbose):
+    sha_path = path + ".sha256"
+    for _url, _path in ((url, path), (sha_url, sha_path)):
+        # see http://serverfault.com/questions/301128/how-to-download
+        if sys.platform == 'win32':
+            run(["PowerShell.exe", "/nologo", "-Command",
+                 "(New-Object System.Net.WebClient)"
+                 ".DownloadFile('{}', '{}')".format(_url, _path)],
+                verbose=verbose)
+        else:
+            run(["curl", "-o", _path, _url], verbose=verbose)
     print("verifying " + path)
     with open(path, "rb") as f:
         found = hashlib.sha256(f.read()).hexdigest()
@@ -69,7 +43,6 @@ def verify(path, sha_path, verbose):
             raise RuntimeError(err)
         sys.exit(err)
 
-
 def unpack(tarball, dst, verbose=False, match=None):
     print("extracting " + tarball)
     fname = os.path.basename(tarball).replace(".tar.gz", "")

branches/try/src/bootstrap/bootstrap.py

@@ -8,29 +8,6 @@
 // option. This file may not be copied, modified, or distributed
 // except according to those terms.
 
-//! C-compiler probing and detection.
-//!
-//! This module will fill out the `cc` and `cxx` maps of `Build` by looking for
-//! C and C++ compilers for each target configured. A compiler is found through
-//! a number of vectors (in order of precedence)
-//!
-//! 1. Configuration via `target.$target.cc` in `config.toml`.
-//! 2. Configuration via `target.$target.android-ndk` in `config.toml`, if
-//!    applicable
-//! 3. Special logic to probe on OpenBSD
-//! 4. The `CC_$target` environment variable.
-//! 5. The `CC` environment variable.
-//! 6. "cc"
-//!
-//! Some of this logic is implemented here, but much of it is farmed out to the
-//! `gcc` crate itself, so we end up having the same fallbacks as there.
-//! Similar logic is then used to find a C++ compiler, just some s/cc/c++/ is
-//! used.
-//!
-//! It is intended that after this module has run no C/C++ compiler will
-//! ever be probed for. Instead the compilers found here will be used for
-//! everything.
-
 use std::process::Command;
 
 use build_helper::{cc2ar, output};