---

yaml
---
r: 276426
b: refs/heads/master
c: 52f48bd
h: refs/heads/master

Author: Manishearth

[refs]

@@ -1,5 +1,5 @@
 ---
-refs/heads/master: 84843b73dc8e54f1e8c1e4418b7d56dbd513dd65
+refs/heads/master: 52f48bdcb5260fa82df840c8224338dd28b7b818
 refs/heads/snap-stage3: 235d77457d80b549dad3ac36d94f235208a1eafb
 refs/heads/try: 49312a405e14a449b98fe0056b12a40ac128be4a
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105

trunk/Makefile.in

@@ -59,9 +59,8 @@
 #   * 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 - show file / line stats
-#   * tidy-errors - show the highest rustc error code
-#   * tidy-features - show the status of language and lib features
+#   * tidy - Basic style check, show highest rustc error code and
+#     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

trunk/configure

@@ -632,6 +632,7 @@ 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"
@@ -1144,6 +1145,15 @@ 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" ]
@@ -1154,7 +1164,7 @@ do
             fi
 
             # Perform a basic sanity check of the NDK
-            for android_ndk_tool in "$ndk/bin/$i-gcc" "$ndk/bin/$i-g++" "$ndk/bin/$i-ar"
+            for android_ndk_tool in "$ndk/bin/$cmd_prefix-gcc" "$ndk/bin/$cmd_prefix-g++" "$ndk/bin/$cmd_prefix-ar"
             do
                 if [ ! -f $android_ndk_tool ]
                 then
@@ -1786,6 +1796,7 @@ 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

trunk/mk/cfg/armv7-linux-androideabi.mk

@@ -0,0 +1,25 @@
+# armv7-linux-androideabi configuration
+CC_armv7-linux-androideabi=$(CFG_ARMV7_LINUX_ANDROIDEABI_NDK)/bin/arm-linux-androideabi-gcc
+CXX_armv7-linux-androideabi=$(CFG_ARMV7_LINUX_ANDROIDEABI_NDK)/bin/arm-linux-androideabi-g++
+CPP_armv7-linux-androideabi=$(CFG_ARMV7_LINUX_ANDROIDEABI_NDK)/bin/arm-linux-androideabi-gcc -E
+AR_armv7-linux-androideabi=$(CFG_ARMV7_LINUX_ANDROIDEABI_NDK)/bin/arm-linux-androideabi-ar
+CFG_LIB_NAME_armv7-linux-androideabi=lib$(1).so
+CFG_STATIC_LIB_NAME_armv7-linux-androideabi=lib$(1).a
+CFG_LIB_GLOB_armv7-linux-androideabi=lib$(1)-*.so
+CFG_LIB_DSYM_GLOB_armv7-linux-androideabi=lib$(1)-*.dylib.dSYM
+CFG_JEMALLOC_CFLAGS_armv7-linux-androideabi := -D__arm__ -DANDROID -D__ANDROID__ $(CFLAGS)
+CFG_GCCISH_CFLAGS_armv7-linux-androideabi := -Wall -g -fPIC -D__arm__ -mfloat-abi=softfp -march=armv7-a -mfpu=vfpv3-d16 -DANDROID -D__ANDROID__ $(CFLAGS)
+CFG_GCCISH_CXXFLAGS_armv7-linux-androideabi := -fno-rtti $(CXXFLAGS)
+CFG_GCCISH_LINK_FLAGS_armv7-linux-androideabi := -shared -fPIC -ldl -g -lm -lsupc++
+CFG_GCCISH_DEF_FLAG_armv7-linux-androideabi := -Wl,--export-dynamic,--dynamic-list=
+CFG_LLC_FLAGS_armv7-linux-androideabi :=
+CFG_INSTALL_NAME_armv7-linux-androideabi =
+CFG_EXE_SUFFIX_armv7-linux-androideabi :=
+CFG_WINDOWSY_armv7-linux-androideabi :=
+CFG_UNIXY_armv7-linux-androideabi := 1
+CFG_LDPATH_armv7-linux-androideabi :=
+CFG_RUN_armv7-linux-androideabi=
+CFG_RUN_TARG_armv7-linux-androideabi=
+RUSTC_FLAGS_armv7-linux-androideabi :=
+RUSTC_CROSS_FLAGS_armv7-linux-androideabi :=
+CFG_GNU_TRIPLE_armv7-linux-androideabi := arm-linux-androideabi

trunk/src/bootstrap/README.md

@@ -1,4 +1,4 @@
-# Bootstrapping Rust
+# rustbuild - 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,20 +8,64 @@ 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 the new build system
+## Using rustbuild
 
 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 `target` directory, which looks
+This build system houses all output under the `build` directory, which looks
 like this:
 
 ```
@@ -42,6 +86,12 @@ 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/
@@ -50,7 +100,8 @@ 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/
@@ -67,6 +118,17 @@ 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
@@ -82,7 +144,9 @@ 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
@@ -96,7 +160,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-rustc/lib/
+    stage0-sysroot/lib/
 
     # These output directories are intended to be standalone working
     # implementations of the compiler (corresponding to each stage). The build
@@ -108,3 +172,69 @@ 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!

trunk/src/bootstrap/bootstrap.py

@@ -16,20 +16,46 @@
 import subprocess
 import sys
 import tarfile
+import tempfile
+
 
 def get(url, path, verbose=False):
-    print("downloading " + url)
     sha_url = url + ".sha256"
-    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)
+    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):
     print("verifying " + path)
     with open(path, "rb") as f:
         found = hashlib.sha256(f.read()).hexdigest()
@@ -43,6 +69,7 @@ def get(url, path, verbose=False):
             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", "")

trunk/src/bootstrap/build/cc.rs

@@ -8,6 +8,29 @@
 // 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};