2016-03-07 23:15:55 -08:00
|
|
|
// Copyright 2016 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2016-11-16 12:31:19 -08:00
|
|
|
//! Implementation of the test-related targets of the build system.
|
2016-05-02 15:16:15 -07:00
|
|
|
//!
|
|
|
|
//! This file implements the various regression test suites that we execute on
|
|
|
|
//! our CI.
|
|
|
|
|
2016-12-17 20:09:23 +01:00
|
|
|
extern crate build_helper;
|
|
|
|
|
2016-10-21 13:18:09 -07:00
|
|
|
use std::collections::HashSet;
|
2016-04-29 14:23:15 -07:00
|
|
|
use std::env;
|
2016-11-25 22:13:59 +01:00
|
|
|
use std::fmt;
|
2016-10-06 23:30:38 -07:00
|
|
|
use std::fs;
|
2016-04-14 18:00:35 -07:00
|
|
|
use std::path::{PathBuf, Path};
|
|
|
|
use std::process::Command;
|
2016-04-14 14:27:51 -07:00
|
|
|
|
2016-04-14 15:51:03 -07:00
|
|
|
use build_helper::output;
|
|
|
|
|
2016-07-05 21:58:20 -07:00
|
|
|
use {Build, Compiler, Mode};
|
2016-12-08 17:13:55 -08:00
|
|
|
use dist;
|
2017-01-28 13:38:06 -08:00
|
|
|
use util::{self, dylib_path, dylib_path_var, exe};
|
2016-06-28 13:31:30 -07:00
|
|
|
|
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the tools to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full and using more cores for the work
at hand. Additionally the architecture here should be a bit speedier as it
should have less overhead than adb which is a whole new process on both the host
and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfully that test suite is much smaller than the run-pass test
suite.
As a final fix I discovered that the ARM and Android test suites were actually
running all library unit tests (e.g. stdtest, coretest, etc) twice. I've
corrected that to only run tests once which should also give a nice boost in
overall cycle time here.
2017-04-26 08:52:19 -07:00
|
|
|
const ADB_TEST_DIR: &'static str = "/data/tmp/work";
|
2016-03-07 23:15:55 -08:00
|
|
|
|
2016-11-25 22:13:59 +01:00
|
|
|
/// The two modes of the test runner; tests or benchmarks.
|
|
|
|
#[derive(Copy, Clone)]
|
|
|
|
pub enum TestKind {
|
|
|
|
/// Run `cargo test`
|
|
|
|
Test,
|
|
|
|
/// Run `cargo bench`
|
|
|
|
Bench,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl TestKind {
|
|
|
|
// Return the cargo subcommand for this test kind
|
|
|
|
fn subcommand(self) -> &'static str {
|
|
|
|
match self {
|
|
|
|
TestKind::Test => "test",
|
|
|
|
TestKind::Bench => "bench",
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl fmt::Display for TestKind {
|
|
|
|
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
|
|
|
|
f.write_str(match *self {
|
|
|
|
TestKind::Test => "Testing",
|
|
|
|
TestKind::Bench => "Benchmarking",
|
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-02 15:16:15 -07:00
|
|
|
/// Runs the `linkchecker` tool as compiled in `stage` by the `host` compiler.
|
|
|
|
///
|
|
|
|
/// This tool in `src/tools` will verify the validity of all our links in the
|
|
|
|
/// documentation to ensure we don't have a bunch of dead ones.
|
2016-12-28 15:01:21 -08:00
|
|
|
pub fn linkcheck(build: &Build, host: &str) {
|
|
|
|
println!("Linkcheck ({})", host);
|
|
|
|
let compiler = Compiler::new(0, host);
|
2016-11-16 12:31:19 -08:00
|
|
|
|
|
|
|
let _time = util::timeit();
|
2016-03-11 16:21:05 -08:00
|
|
|
build.run(build.tool_cmd(&compiler, "linkchecker")
|
|
|
|
.arg(build.out.join(host).join("doc")));
|
2016-03-07 23:15:55 -08:00
|
|
|
}
|
2016-03-18 20:54:31 +00:00
|
|
|
|
2016-05-02 15:16:15 -07:00
|
|
|
/// Runs the `cargotest` tool as compiled in `stage` by the `host` compiler.
|
|
|
|
///
|
|
|
|
/// This tool in `src/tools` will check out a few Rust projects and run `cargo
|
|
|
|
/// test` to ensure that we don't regress the test suites there.
|
2016-03-18 20:54:31 +00:00
|
|
|
pub fn cargotest(build: &Build, stage: u32, host: &str) {
|
|
|
|
let ref compiler = Compiler::new(stage, host);
|
2016-04-06 18:03:42 +00:00
|
|
|
|
2016-04-14 14:27:51 -07:00
|
|
|
// Note that this is a short, cryptic, and not scoped directory name. This
|
|
|
|
// is currently to minimize the length of path on Windows where we otherwise
|
|
|
|
// quickly run into path name limit constraints.
|
|
|
|
let out_dir = build.out.join("ct");
|
|
|
|
t!(fs::create_dir_all(&out_dir));
|
|
|
|
|
2016-11-16 12:31:19 -08:00
|
|
|
let _time = util::timeit();
|
2016-12-28 15:01:21 -08:00
|
|
|
let mut cmd = Command::new(build.tool(&Compiler::new(0, host), "cargotest"));
|
|
|
|
build.prepare_tool_cmd(compiler, &mut cmd);
|
2017-04-17 17:24:05 -07:00
|
|
|
build.run(cmd.arg(&build.cargo)
|
|
|
|
.arg(&out_dir)
|
|
|
|
.env("RUSTC", build.compiler_path(compiler))
|
|
|
|
.env("RUSTDOC", build.rustdoc(compiler)))
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Runs `cargo test` for `cargo` packaged with Rust.
|
|
|
|
pub fn cargo(build: &Build, stage: u32, host: &str) {
|
|
|
|
let ref compiler = Compiler::new(stage, host);
|
|
|
|
|
|
|
|
// Configure PATH to find the right rustc. NB. we have to use PATH
|
|
|
|
// and not RUSTC because the Cargo test suite has tests that will
|
|
|
|
// fail if rustc is not spelled `rustc`.
|
|
|
|
let path = build.sysroot(compiler).join("bin");
|
|
|
|
let old_path = ::std::env::var("PATH").expect("");
|
|
|
|
let sep = if cfg!(windows) { ";" } else {":" };
|
|
|
|
let ref newpath = format!("{}{}{}", path.display(), sep, old_path);
|
|
|
|
|
|
|
|
let mut cargo = build.cargo(compiler, Mode::Tool, host, "test");
|
2017-04-20 14:32:54 -07:00
|
|
|
cargo.arg("--manifest-path").arg(build.src.join("src/tools/cargo/Cargo.toml"));
|
2017-04-17 17:24:05 -07:00
|
|
|
|
|
|
|
// Don't build tests dynamically, just a pain to work with
|
|
|
|
cargo.env("RUSTC_NO_PREFER_DYNAMIC", "1");
|
|
|
|
|
|
|
|
// Don't run cross-compile tests, we may not have cross-compiled libstd libs
|
|
|
|
// available.
|
|
|
|
cargo.env("CFG_DISABLE_CROSS_TESTS", "1");
|
|
|
|
|
|
|
|
build.run(cargo.env("PATH", newpath));
|
2016-03-18 20:54:31 +00:00
|
|
|
}
|
2016-03-29 13:14:52 -07:00
|
|
|
|
2016-05-02 15:16:15 -07:00
|
|
|
/// Runs the `tidy` tool as compiled in `stage` by the `host` compiler.
|
|
|
|
///
|
|
|
|
/// This tool in `src/tools` checks up on various bits and pieces of style and
|
|
|
|
/// otherwise just implements a few lint-like checks that are specific to the
|
|
|
|
/// compiler itself.
|
2016-12-28 15:01:21 -08:00
|
|
|
pub fn tidy(build: &Build, host: &str) {
|
2017-05-18 00:33:20 +08:00
|
|
|
let _folder = build.fold_output(|| "tidy");
|
2016-12-28 15:01:21 -08:00
|
|
|
println!("tidy check ({})", host);
|
|
|
|
let compiler = Compiler::new(0, host);
|
2017-02-10 22:59:40 +02:00
|
|
|
let mut cmd = build.tool_cmd(&compiler, "tidy");
|
|
|
|
cmd.arg(build.src.join("src"));
|
|
|
|
if !build.config.vendor {
|
|
|
|
cmd.arg("--no-vendor");
|
|
|
|
}
|
2017-05-22 04:27:47 +08:00
|
|
|
if build.config.quiet_tests {
|
|
|
|
cmd.arg("--quiet");
|
|
|
|
}
|
2017-02-10 22:59:40 +02:00
|
|
|
build.run(&mut cmd);
|
2016-03-29 13:14:52 -07:00
|
|
|
}
|
2016-04-05 11:34:23 -07:00
|
|
|
|
|
|
|
fn testdir(build: &Build, host: &str) -> PathBuf {
|
|
|
|
build.out.join(host).join("test")
|
|
|
|
}
|
|
|
|
|
2016-05-02 15:16:15 -07:00
|
|
|
/// Executes the `compiletest` tool to run a suite of tests.
|
|
|
|
///
|
|
|
|
/// Compiles all tests with `compiler` for `target` with the specified
|
|
|
|
/// compiletest `mode` and `suite` arguments. For example `mode` can be
|
|
|
|
/// "run-pass" or `suite` can be something like `debuginfo`.
|
2016-04-05 11:34:23 -07:00
|
|
|
pub fn compiletest(build: &Build,
|
|
|
|
compiler: &Compiler,
|
|
|
|
target: &str,
|
|
|
|
mode: &str,
|
|
|
|
suite: &str) {
|
2017-05-18 00:33:20 +08:00
|
|
|
let _folder = build.fold_output(|| format!("test_{}", suite));
|
2016-11-16 12:31:19 -08:00
|
|
|
println!("Check compiletest suite={} mode={} ({} -> {})",
|
|
|
|
suite, mode, compiler.host, target);
|
2016-12-28 15:01:21 -08:00
|
|
|
let mut cmd = Command::new(build.tool(&Compiler::new(0, compiler.host),
|
|
|
|
"compiletest"));
|
|
|
|
build.prepare_tool_cmd(compiler, &mut cmd);
|
2016-04-05 11:34:23 -07:00
|
|
|
|
2016-05-02 15:16:15 -07:00
|
|
|
// compiletest currently has... a lot of arguments, so let's just pass all
|
|
|
|
// of them!
|
|
|
|
|
2016-04-05 11:34:23 -07:00
|
|
|
cmd.arg("--compile-lib-path").arg(build.rustc_libdir(compiler));
|
|
|
|
cmd.arg("--run-lib-path").arg(build.sysroot_libdir(compiler, target));
|
|
|
|
cmd.arg("--rustc-path").arg(build.compiler_path(compiler));
|
|
|
|
cmd.arg("--rustdoc-path").arg(build.rustdoc(compiler));
|
|
|
|
cmd.arg("--src-base").arg(build.src.join("src/test").join(suite));
|
|
|
|
cmd.arg("--build-base").arg(testdir(build, compiler.host).join(suite));
|
|
|
|
cmd.arg("--stage-id").arg(format!("stage{}-{}", compiler.stage, target));
|
|
|
|
cmd.arg("--mode").arg(mode);
|
|
|
|
cmd.arg("--target").arg(target);
|
|
|
|
cmd.arg("--host").arg(compiler.host);
|
|
|
|
cmd.arg("--llvm-filecheck").arg(build.llvm_filecheck(&build.config.build));
|
|
|
|
|
2016-09-15 19:42:26 +00:00
|
|
|
if let Some(nodejs) = build.config.nodejs.as_ref() {
|
|
|
|
cmd.arg("--nodejs").arg(nodejs);
|
|
|
|
}
|
|
|
|
|
2016-06-28 13:31:30 -07:00
|
|
|
let mut flags = vec!["-Crpath".to_string()];
|
2016-05-13 15:26:41 -07:00
|
|
|
if build.config.rust_optimize_tests {
|
2016-06-28 13:31:30 -07:00
|
|
|
flags.push("-O".to_string());
|
2016-05-13 15:26:41 -07:00
|
|
|
}
|
|
|
|
if build.config.rust_debuginfo_tests {
|
2016-06-28 13:31:30 -07:00
|
|
|
flags.push("-g".to_string());
|
2016-05-13 15:26:41 -07:00
|
|
|
}
|
|
|
|
|
2016-06-28 13:31:30 -07:00
|
|
|
let mut hostflags = build.rustc_flags(&compiler.host);
|
|
|
|
hostflags.extend(flags.clone());
|
|
|
|
cmd.arg("--host-rustcflags").arg(hostflags.join(" "));
|
2016-04-05 11:34:23 -07:00
|
|
|
|
2016-06-28 13:31:30 -07:00
|
|
|
let mut targetflags = build.rustc_flags(&target);
|
|
|
|
targetflags.extend(flags);
|
|
|
|
targetflags.push(format!("-Lnative={}",
|
|
|
|
build.test_helpers_out(target).display()));
|
|
|
|
cmd.arg("--target-rustcflags").arg(targetflags.join(" "));
|
2016-04-19 09:44:19 -07:00
|
|
|
|
2016-11-14 08:04:39 -08:00
|
|
|
cmd.arg("--docck-python").arg(build.python());
|
2016-04-19 09:44:19 -07:00
|
|
|
|
|
|
|
if build.config.build.ends_with("apple-darwin") {
|
2017-03-12 14:13:35 -04:00
|
|
|
// Force /usr/bin/python on macOS for LLDB tests because we're loading the
|
2016-04-19 09:44:19 -07:00
|
|
|
// LLDB plugin's compiled module which only works with the system python
|
|
|
|
// (namely not Homebrew-installed python)
|
|
|
|
cmd.arg("--lldb-python").arg("/usr/bin/python");
|
|
|
|
} else {
|
2016-11-14 08:04:39 -08:00
|
|
|
cmd.arg("--lldb-python").arg(build.python());
|
2016-04-19 09:44:19 -07:00
|
|
|
}
|
2016-04-05 11:34:23 -07:00
|
|
|
|
2016-10-29 20:11:53 +02:00
|
|
|
if let Some(ref gdb) = build.config.gdb {
|
|
|
|
cmd.arg("--gdb").arg(gdb);
|
2016-04-05 11:34:23 -07:00
|
|
|
}
|
|
|
|
if let Some(ref vers) = build.lldb_version {
|
|
|
|
cmd.arg("--lldb-version").arg(vers);
|
|
|
|
}
|
|
|
|
if let Some(ref dir) = build.lldb_python_dir {
|
|
|
|
cmd.arg("--lldb-python-dir").arg(dir);
|
|
|
|
}
|
2016-09-01 10:52:44 -07:00
|
|
|
let llvm_config = build.llvm_config(target);
|
|
|
|
let llvm_version = output(Command::new(&llvm_config).arg("--version"));
|
|
|
|
cmd.arg("--llvm-version").arg(llvm_version);
|
2016-04-05 11:34:23 -07:00
|
|
|
|
2016-10-21 13:18:09 -07:00
|
|
|
cmd.args(&build.flags.cmd.test_args());
|
2016-04-05 11:34:23 -07:00
|
|
|
|
2016-11-16 18:02:56 -05:00
|
|
|
if build.config.verbose() || build.flags.verbose() {
|
2016-04-05 11:34:23 -07:00
|
|
|
cmd.arg("--verbose");
|
|
|
|
}
|
|
|
|
|
2016-10-29 21:58:52 -04:00
|
|
|
if build.config.quiet_tests {
|
|
|
|
cmd.arg("--quiet");
|
|
|
|
}
|
|
|
|
|
2016-05-02 15:16:15 -07:00
|
|
|
// Only pass correct values for these flags for the `run-make` suite as it
|
|
|
|
// requires that a C++ compiler was configured which isn't always the case.
|
2016-04-14 15:51:03 -07:00
|
|
|
if suite == "run-make" {
|
|
|
|
let llvm_components = output(Command::new(&llvm_config).arg("--components"));
|
|
|
|
let llvm_cxxflags = output(Command::new(&llvm_config).arg("--cxxflags"));
|
|
|
|
cmd.arg("--cc").arg(build.cc(target))
|
|
|
|
.arg("--cxx").arg(build.cxx(target))
|
|
|
|
.arg("--cflags").arg(build.cflags(target).join(" "))
|
|
|
|
.arg("--llvm-components").arg(llvm_components.trim())
|
|
|
|
.arg("--llvm-cxxflags").arg(llvm_cxxflags.trim());
|
|
|
|
} else {
|
|
|
|
cmd.arg("--cc").arg("")
|
|
|
|
.arg("--cxx").arg("")
|
|
|
|
.arg("--cflags").arg("")
|
|
|
|
.arg("--llvm-components").arg("")
|
|
|
|
.arg("--llvm-cxxflags").arg("");
|
|
|
|
}
|
|
|
|
|
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the tools to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full and using more cores for the work
at hand. Additionally the architecture here should be a bit speedier as it
should have less overhead than adb which is a whole new process on both the host
and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfully that test suite is much smaller than the run-pass test
suite.
As a final fix I discovered that the ARM and Android test suites were actually
running all library unit tests (e.g. stdtest, coretest, etc) twice. I've
corrected that to only run tests once which should also give a nice boost in
overall cycle time here.
2017-04-26 08:52:19 -07:00
|
|
|
if build.remote_tested(target) {
|
|
|
|
cmd.arg("--remote-test-client")
|
2017-01-28 13:38:06 -08:00
|
|
|
.arg(build.tool(&Compiler::new(0, &build.config.build),
|
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the tools to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full and using more cores for the work
at hand. Additionally the architecture here should be a bit speedier as it
should have less overhead than adb which is a whole new process on both the host
and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfully that test suite is much smaller than the run-pass test
suite.
As a final fix I discovered that the ARM and Android test suites were actually
running all library unit tests (e.g. stdtest, coretest, etc) twice. I've
corrected that to only run tests once which should also give a nice boost in
overall cycle time here.
2017-04-26 08:52:19 -07:00
|
|
|
"remote-test-client"));
|
2017-01-28 13:38:06 -08:00
|
|
|
}
|
|
|
|
|
2016-04-14 15:51:03 -07:00
|
|
|
// Running a C compiler on MSVC requires a few env vars to be set, to be
|
|
|
|
// sure to set them here.
|
2016-11-16 12:31:19 -08:00
|
|
|
//
|
|
|
|
// Note that if we encounter `PATH` we make sure to append to our own `PATH`
|
|
|
|
// rather than stomp over it.
|
2016-04-14 15:51:03 -07:00
|
|
|
if target.contains("msvc") {
|
|
|
|
for &(ref k, ref v) in build.cc[target].0.env() {
|
|
|
|
if k != "PATH" {
|
|
|
|
cmd.env(k, v);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2016-11-16 09:19:02 -08:00
|
|
|
cmd.env("RUSTC_BOOTSTRAP", "1");
|
2016-11-16 12:31:19 -08:00
|
|
|
build.add_rust_test_threads(&mut cmd);
|
2016-04-14 15:51:03 -07:00
|
|
|
|
2017-02-03 18:58:47 -05:00
|
|
|
if build.config.sanitizers {
|
|
|
|
cmd.env("SANITIZER_SUPPORT", "1");
|
|
|
|
}
|
|
|
|
|
2016-06-28 13:31:30 -07:00
|
|
|
cmd.arg("--adb-path").arg("adb");
|
|
|
|
cmd.arg("--adb-test-dir").arg(ADB_TEST_DIR);
|
|
|
|
if target.contains("android") {
|
|
|
|
// Assume that cc for this target comes from the android sysroot
|
|
|
|
cmd.arg("--android-cross-path")
|
|
|
|
.arg(build.cc(target).parent().unwrap().parent().unwrap());
|
|
|
|
} else {
|
|
|
|
cmd.arg("--android-cross-path").arg("");
|
|
|
|
}
|
|
|
|
|
2017-05-18 00:33:20 +08:00
|
|
|
build.ci_env.force_coloring_in_ci(&mut cmd);
|
|
|
|
|
2016-11-16 12:31:19 -08:00
|
|
|
let _time = util::timeit();
|
2016-04-05 11:34:23 -07:00
|
|
|
build.run(&mut cmd);
|
|
|
|
}
|
2016-04-14 18:00:35 -07:00
|
|
|
|
2016-05-02 15:16:15 -07:00
|
|
|
/// Run `rustdoc --test` for all documentation in `src/doc`.
|
|
|
|
///
|
|
|
|
/// This will run all tests in our markdown documentation (e.g. the book)
|
|
|
|
/// located in `src/doc`. The `rustdoc` that's run is the one that sits next to
|
|
|
|
/// `compiler`.
|
2016-04-14 18:00:35 -07:00
|
|
|
pub fn docs(build: &Build, compiler: &Compiler) {
|
2016-05-02 15:16:15 -07:00
|
|
|
// Do a breadth-first traversal of the `src/doc` directory and just run
|
|
|
|
// tests for all files that end in `*.md`
|
2016-04-14 18:00:35 -07:00
|
|
|
let mut stack = vec![build.src.join("src/doc")];
|
2016-11-16 12:31:19 -08:00
|
|
|
let _time = util::timeit();
|
2017-05-18 00:33:20 +08:00
|
|
|
let _folder = build.fold_output(|| "test_docs");
|
2016-04-14 18:00:35 -07:00
|
|
|
|
|
|
|
while let Some(p) = stack.pop() {
|
|
|
|
if p.is_dir() {
|
|
|
|
stack.extend(t!(p.read_dir()).map(|p| t!(p).path()));
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
if p.extension().and_then(|s| s.to_str()) != Some("md") {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
2017-03-13 16:41:31 -04:00
|
|
|
// The nostarch directory in the book is for no starch, and so isn't guaranteed to build.
|
|
|
|
// we don't care if it doesn't build, so skip it.
|
|
|
|
use std::ffi::OsStr;
|
|
|
|
let path: &OsStr = p.as_ref();
|
|
|
|
if let Some(path) = path.to_str() {
|
|
|
|
if path.contains("nostarch") {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-04-14 18:00:35 -07:00
|
|
|
println!("doc tests for: {}", p.display());
|
|
|
|
markdown_test(build, compiler, &p);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-02 15:16:15 -07:00
|
|
|
/// Run the error index generator tool to execute the tests located in the error
|
|
|
|
/// index.
|
|
|
|
///
|
|
|
|
/// The `error_index_generator` tool lives in `src/tools` and is used to
|
|
|
|
/// generate a markdown file from the error indexes of the code base which is
|
|
|
|
/// then passed to `rustdoc --test`.
|
2016-04-14 18:00:35 -07:00
|
|
|
pub fn error_index(build: &Build, compiler: &Compiler) {
|
2017-05-18 00:33:20 +08:00
|
|
|
let _folder = build.fold_output(|| "test_error_index");
|
2016-04-14 18:00:35 -07:00
|
|
|
println!("Testing error-index stage{}", compiler.stage);
|
|
|
|
|
2016-11-08 09:59:46 -08:00
|
|
|
let dir = testdir(build, compiler.host);
|
|
|
|
t!(fs::create_dir_all(&dir));
|
|
|
|
let output = dir.join("error-index.md");
|
2016-11-16 12:31:19 -08:00
|
|
|
|
|
|
|
let _time = util::timeit();
|
2016-12-28 15:01:21 -08:00
|
|
|
build.run(build.tool_cmd(&Compiler::new(0, compiler.host),
|
|
|
|
"error_index_generator")
|
2016-04-14 18:00:35 -07:00
|
|
|
.arg("markdown")
|
|
|
|
.arg(&output)
|
|
|
|
.env("CFG_BUILD", &build.config.build));
|
|
|
|
|
|
|
|
markdown_test(build, compiler, &output);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn markdown_test(build: &Build, compiler: &Compiler, markdown: &Path) {
|
|
|
|
let mut cmd = Command::new(build.rustdoc(compiler));
|
|
|
|
build.add_rustc_lib_path(compiler, &mut cmd);
|
2016-11-16 12:31:19 -08:00
|
|
|
build.add_rust_test_threads(&mut cmd);
|
2016-04-14 18:00:35 -07:00
|
|
|
cmd.arg("--test");
|
|
|
|
cmd.arg(markdown);
|
2016-12-12 09:03:35 -08:00
|
|
|
cmd.env("RUSTC_BOOTSTRAP", "1");
|
2016-10-29 21:58:52 -04:00
|
|
|
|
2017-05-22 04:27:47 +08:00
|
|
|
let test_args = build.flags.cmd.test_args().join(" ");
|
2016-10-29 21:58:52 -04:00
|
|
|
cmd.arg("--test-args").arg(test_args);
|
|
|
|
|
2017-05-22 04:27:47 +08:00
|
|
|
if build.config.quiet_tests {
|
|
|
|
build.run_quiet(&mut cmd);
|
|
|
|
} else {
|
|
|
|
build.run(&mut cmd);
|
|
|
|
}
|
2016-04-14 18:00:35 -07:00
|
|
|
}
|
2016-04-29 14:23:15 -07:00
|
|
|
|
|
|
|
/// Run all unit tests plus documentation tests for an entire crate DAG defined
|
|
|
|
/// by a `Cargo.toml`
|
|
|
|
///
|
|
|
|
/// This is what runs tests for crates like the standard library, compiler, etc.
|
|
|
|
/// It essentially is the driver for running `cargo test`.
|
|
|
|
///
|
|
|
|
/// Currently this runs all tests for a DAG by passing a bunch of `-p foo`
|
2016-10-06 23:30:38 -07:00
|
|
|
/// arguments, and those arguments are discovered from `cargo metadata`.
|
2016-04-29 14:23:15 -07:00
|
|
|
pub fn krate(build: &Build,
|
|
|
|
compiler: &Compiler,
|
|
|
|
target: &str,
|
2016-10-21 13:18:09 -07:00
|
|
|
mode: Mode,
|
2016-11-25 22:13:59 +01:00
|
|
|
test_kind: TestKind,
|
2016-10-21 13:18:09 -07:00
|
|
|
krate: Option<&str>) {
|
2016-10-06 23:30:38 -07:00
|
|
|
let (name, path, features, root) = match mode {
|
2016-09-02 01:55:29 -07:00
|
|
|
Mode::Libstd => {
|
2017-02-15 08:53:18 -08:00
|
|
|
("libstd", "src/libstd", build.std_features(), "std")
|
2016-09-02 01:55:29 -07:00
|
|
|
}
|
|
|
|
Mode::Libtest => {
|
2017-02-15 08:53:18 -08:00
|
|
|
("libtest", "src/libtest", String::new(), "test")
|
2016-09-02 01:55:29 -07:00
|
|
|
}
|
|
|
|
Mode::Librustc => {
|
2016-10-06 23:30:38 -07:00
|
|
|
("librustc", "src/rustc", build.rustc_features(), "rustc-main")
|
2016-09-02 01:55:29 -07:00
|
|
|
}
|
2016-04-29 14:23:15 -07:00
|
|
|
_ => panic!("can only test libraries"),
|
|
|
|
};
|
2017-05-18 00:33:20 +08:00
|
|
|
let _folder = build.fold_output(|| {
|
|
|
|
format!("{}_stage{}-{}", test_kind.subcommand(), compiler.stage, name)
|
|
|
|
});
|
2016-11-25 22:13:59 +01:00
|
|
|
println!("{} {} stage{} ({} -> {})", test_kind, name, compiler.stage,
|
2016-04-29 14:23:15 -07:00
|
|
|
compiler.host, target);
|
|
|
|
|
rustbuild: Compile rustc twice, not thrice
This commit switches the rustbuild build system to compiling the
compiler twice for a normal bootstrap rather than the historical three
times.
Rust is a bootstrapped language which means that a previous version of
the compiler is used to build the next version of the compiler. Over
time, however, we change many parts of compiler artifacts such as the
metadata format, symbol names, etc. These changes make artifacts from
one compiler incompatible from another compiler. Consequently if a
compiler wants to be able to use some artifacts then it itself must have
compiled the artifacts.
Historically the rustc build system has achieved this by compiling the
compiler three times:
* An older compiler (stage0) is downloaded to kick off the chain.
* This compiler now compiles a new compiler (stage1)
* The stage1 compiler then compiles another compiler (stage2)
* Finally, the stage2 compiler needs libraries to link against, so it
compiles all the libraries again.
This entire process amounts in compiling the compiler three times.
Additionally, this process always guarantees that the Rust source tree
can compile itself because the stage2 compiler (created by a freshly
created compiler) would successfully compile itself again. This
property, ensuring Rust can compile itself, is quite important!
In general, though, this third compilation is not required for general
purpose development on the compiler. The third compiler (stage2) can
reuse the libraries that were created during the second compile. In
other words, the second compilation can produce both a compiler and the
libraries that compiler will use. These artifacts *must* be compatible
due to the way plugins work today anyway, and they were created by the
same source code so they *should* be compatible as well.
So given all that, this commit switches the default build process to
only compile the compiler three times, avoiding this third compilation
by copying artifacts from the previous one. Along the way a new entry in
the Travis matrix was also added to ensure that our full bootstrap can
succeed. This entry does not run tests, though, as it should not be
necessary.
To restore the old behavior of a full bootstrap (three compiles) you can
either pass:
./configure --enable-full-bootstrap
or if you're using config.toml:
[build]
full-bootstrap = true
Overall this will hopefully be an easy 33% win in build times of the
compiler. If we do 33% less work we should be 33% faster! This in turn
should affect cycle times and such on Travis and AppVeyor positively as
well as making it easier to work on the compiler itself.
2016-12-25 15:20:33 -08:00
|
|
|
// If we're not doing a full bootstrap but we're testing a stage2 version of
|
|
|
|
// libstd, then what we're actually testing is the libstd produced in
|
|
|
|
// stage1. Reflect that here by updating the compiler that we're working
|
|
|
|
// with automatically.
|
|
|
|
let compiler = if build.force_use_stage1(compiler, target) {
|
|
|
|
Compiler::new(1, compiler.host)
|
|
|
|
} else {
|
|
|
|
compiler.clone()
|
|
|
|
};
|
|
|
|
|
2016-04-29 14:23:15 -07:00
|
|
|
// Build up the base `cargo test` command.
|
2016-10-06 23:30:38 -07:00
|
|
|
//
|
|
|
|
// Pass in some standard flags then iterate over the graph we've discovered
|
|
|
|
// in `cargo metadata` with the maps above and figure out what `-p`
|
|
|
|
// arguments need to get passed.
|
rustbuild: Compile rustc twice, not thrice
This commit switches the rustbuild build system to compiling the
compiler twice for a normal bootstrap rather than the historical three
times.
Rust is a bootstrapped language which means that a previous version of
the compiler is used to build the next version of the compiler. Over
time, however, we change many parts of compiler artifacts such as the
metadata format, symbol names, etc. These changes make artifacts from
one compiler incompatible from another compiler. Consequently if a
compiler wants to be able to use some artifacts then it itself must have
compiled the artifacts.
Historically the rustc build system has achieved this by compiling the
compiler three times:
* An older compiler (stage0) is downloaded to kick off the chain.
* This compiler now compiles a new compiler (stage1)
* The stage1 compiler then compiles another compiler (stage2)
* Finally, the stage2 compiler needs libraries to link against, so it
compiles all the libraries again.
This entire process amounts in compiling the compiler three times.
Additionally, this process always guarantees that the Rust source tree
can compile itself because the stage2 compiler (created by a freshly
created compiler) would successfully compile itself again. This
property, ensuring Rust can compile itself, is quite important!
In general, though, this third compilation is not required for general
purpose development on the compiler. The third compiler (stage2) can
reuse the libraries that were created during the second compile. In
other words, the second compilation can produce both a compiler and the
libraries that compiler will use. These artifacts *must* be compatible
due to the way plugins work today anyway, and they were created by the
same source code so they *should* be compatible as well.
So given all that, this commit switches the default build process to
only compile the compiler three times, avoiding this third compilation
by copying artifacts from the previous one. Along the way a new entry in
the Travis matrix was also added to ensure that our full bootstrap can
succeed. This entry does not run tests, though, as it should not be
necessary.
To restore the old behavior of a full bootstrap (three compiles) you can
either pass:
./configure --enable-full-bootstrap
or if you're using config.toml:
[build]
full-bootstrap = true
Overall this will hopefully be an easy 33% win in build times of the
compiler. If we do 33% less work we should be 33% faster! This in turn
should affect cycle times and such on Travis and AppVeyor positively as
well as making it easier to work on the compiler itself.
2016-12-25 15:20:33 -08:00
|
|
|
let mut cargo = build.cargo(&compiler, mode, target, test_kind.subcommand());
|
2016-04-29 14:23:15 -07:00
|
|
|
cargo.arg("--manifest-path")
|
|
|
|
.arg(build.src.join(path).join("Cargo.toml"))
|
|
|
|
.arg("--features").arg(features);
|
|
|
|
|
2016-10-21 13:18:09 -07:00
|
|
|
match krate {
|
|
|
|
Some(krate) => {
|
|
|
|
cargo.arg("-p").arg(krate);
|
2016-04-29 14:23:15 -07:00
|
|
|
}
|
2016-10-21 13:18:09 -07:00
|
|
|
None => {
|
|
|
|
let mut visited = HashSet::new();
|
|
|
|
let mut next = vec![root];
|
|
|
|
while let Some(name) = next.pop() {
|
2017-01-13 15:11:34 -08:00
|
|
|
// Right now jemalloc is our only target-specific crate in the
|
|
|
|
// sense that it's not present on all platforms. Custom skip it
|
|
|
|
// here for now, but if we add more this probably wants to get
|
|
|
|
// more generalized.
|
|
|
|
//
|
|
|
|
// Also skip `build_helper` as it's not compiled normally for
|
|
|
|
// target during the bootstrap and it's just meant to be a
|
|
|
|
// helper crate, not tested. If it leaks through then it ends up
|
|
|
|
// messing with various mtime calculations and such.
|
|
|
|
if !name.contains("jemalloc") && name != "build_helper" {
|
2017-02-02 23:55:42 +03:00
|
|
|
cargo.arg("-p").arg(&format!("{}:0.0.0", name));
|
2016-10-21 13:18:09 -07:00
|
|
|
}
|
|
|
|
for dep in build.crates[name].deps.iter() {
|
|
|
|
if visited.insert(dep) {
|
|
|
|
next.push(dep);
|
|
|
|
}
|
|
|
|
}
|
2016-10-06 23:30:38 -07:00
|
|
|
}
|
2016-04-29 14:23:15 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// The tests are going to run with the *target* libraries, so we need to
|
|
|
|
// ensure that those libraries show up in the LD_LIBRARY_PATH equivalent.
|
|
|
|
//
|
|
|
|
// Note that to run the compiler we need to run with the *host* libraries,
|
|
|
|
// but our wrapper scripts arrange for that to be the case anyway.
|
|
|
|
let mut dylib_path = dylib_path();
|
rustbuild: Compile rustc twice, not thrice
This commit switches the rustbuild build system to compiling the
compiler twice for a normal bootstrap rather than the historical three
times.
Rust is a bootstrapped language which means that a previous version of
the compiler is used to build the next version of the compiler. Over
time, however, we change many parts of compiler artifacts such as the
metadata format, symbol names, etc. These changes make artifacts from
one compiler incompatible from another compiler. Consequently if a
compiler wants to be able to use some artifacts then it itself must have
compiled the artifacts.
Historically the rustc build system has achieved this by compiling the
compiler three times:
* An older compiler (stage0) is downloaded to kick off the chain.
* This compiler now compiles a new compiler (stage1)
* The stage1 compiler then compiles another compiler (stage2)
* Finally, the stage2 compiler needs libraries to link against, so it
compiles all the libraries again.
This entire process amounts in compiling the compiler three times.
Additionally, this process always guarantees that the Rust source tree
can compile itself because the stage2 compiler (created by a freshly
created compiler) would successfully compile itself again. This
property, ensuring Rust can compile itself, is quite important!
In general, though, this third compilation is not required for general
purpose development on the compiler. The third compiler (stage2) can
reuse the libraries that were created during the second compile. In
other words, the second compilation can produce both a compiler and the
libraries that compiler will use. These artifacts *must* be compatible
due to the way plugins work today anyway, and they were created by the
same source code so they *should* be compatible as well.
So given all that, this commit switches the default build process to
only compile the compiler three times, avoiding this third compilation
by copying artifacts from the previous one. Along the way a new entry in
the Travis matrix was also added to ensure that our full bootstrap can
succeed. This entry does not run tests, though, as it should not be
necessary.
To restore the old behavior of a full bootstrap (three compiles) you can
either pass:
./configure --enable-full-bootstrap
or if you're using config.toml:
[build]
full-bootstrap = true
Overall this will hopefully be an easy 33% win in build times of the
compiler. If we do 33% less work we should be 33% faster! This in turn
should affect cycle times and such on Travis and AppVeyor positively as
well as making it easier to work on the compiler itself.
2016-12-25 15:20:33 -08:00
|
|
|
dylib_path.insert(0, build.sysroot_libdir(&compiler, target));
|
2016-04-29 14:23:15 -07:00
|
|
|
cargo.env(dylib_path_var(), env::join_paths(&dylib_path).unwrap());
|
|
|
|
|
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the tools to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full and using more cores for the work
at hand. Additionally the architecture here should be a bit speedier as it
should have less overhead than adb which is a whole new process on both the host
and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfully that test suite is much smaller than the run-pass test
suite.
As a final fix I discovered that the ARM and Android test suites were actually
running all library unit tests (e.g. stdtest, coretest, etc) twice. I've
corrected that to only run tests once which should also give a nice boost in
overall cycle time here.
2017-04-26 08:52:19 -07:00
|
|
|
if target.contains("emscripten") || build.remote_tested(target) {
|
2016-11-16 12:31:19 -08:00
|
|
|
cargo.arg("--no-run");
|
|
|
|
}
|
|
|
|
|
|
|
|
cargo.arg("--");
|
|
|
|
|
2016-10-29 21:58:52 -04:00
|
|
|
if build.config.quiet_tests {
|
|
|
|
cargo.arg("--quiet");
|
|
|
|
}
|
|
|
|
|
2016-11-16 12:31:19 -08:00
|
|
|
let _time = util::timeit();
|
|
|
|
|
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the tools to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full and using more cores for the work
at hand. Additionally the architecture here should be a bit speedier as it
should have less overhead than adb which is a whole new process on both the host
and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfully that test suite is much smaller than the run-pass test
suite.
As a final fix I discovered that the ARM and Android test suites were actually
running all library unit tests (e.g. stdtest, coretest, etc) twice. I've
corrected that to only run tests once which should also give a nice boost in
overall cycle time here.
2017-04-26 08:52:19 -07:00
|
|
|
if target.contains("emscripten") {
|
2016-11-16 12:31:19 -08:00
|
|
|
build.run(&mut cargo);
|
rustbuild: Compile rustc twice, not thrice
This commit switches the rustbuild build system to compiling the
compiler twice for a normal bootstrap rather than the historical three
times.
Rust is a bootstrapped language which means that a previous version of
the compiler is used to build the next version of the compiler. Over
time, however, we change many parts of compiler artifacts such as the
metadata format, symbol names, etc. These changes make artifacts from
one compiler incompatible from another compiler. Consequently if a
compiler wants to be able to use some artifacts then it itself must have
compiled the artifacts.
Historically the rustc build system has achieved this by compiling the
compiler three times:
* An older compiler (stage0) is downloaded to kick off the chain.
* This compiler now compiles a new compiler (stage1)
* The stage1 compiler then compiles another compiler (stage2)
* Finally, the stage2 compiler needs libraries to link against, so it
compiles all the libraries again.
This entire process amounts in compiling the compiler three times.
Additionally, this process always guarantees that the Rust source tree
can compile itself because the stage2 compiler (created by a freshly
created compiler) would successfully compile itself again. This
property, ensuring Rust can compile itself, is quite important!
In general, though, this third compilation is not required for general
purpose development on the compiler. The third compiler (stage2) can
reuse the libraries that were created during the second compile. In
other words, the second compilation can produce both a compiler and the
libraries that compiler will use. These artifacts *must* be compatible
due to the way plugins work today anyway, and they were created by the
same source code so they *should* be compatible as well.
So given all that, this commit switches the default build process to
only compile the compiler three times, avoiding this third compilation
by copying artifacts from the previous one. Along the way a new entry in
the Travis matrix was also added to ensure that our full bootstrap can
succeed. This entry does not run tests, though, as it should not be
necessary.
To restore the old behavior of a full bootstrap (three compiles) you can
either pass:
./configure --enable-full-bootstrap
or if you're using config.toml:
[build]
full-bootstrap = true
Overall this will hopefully be an easy 33% win in build times of the
compiler. If we do 33% less work we should be 33% faster! This in turn
should affect cycle times and such on Travis and AppVeyor positively as
well as making it easier to work on the compiler itself.
2016-12-25 15:20:33 -08:00
|
|
|
krate_emscripten(build, &compiler, target, mode);
|
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the tools to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full and using more cores for the work
at hand. Additionally the architecture here should be a bit speedier as it
should have less overhead than adb which is a whole new process on both the host
and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfully that test suite is much smaller than the run-pass test
suite.
As a final fix I discovered that the ARM and Android test suites were actually
running all library unit tests (e.g. stdtest, coretest, etc) twice. I've
corrected that to only run tests once which should also give a nice boost in
overall cycle time here.
2017-04-26 08:52:19 -07:00
|
|
|
} else if build.remote_tested(target) {
|
2017-01-28 13:38:06 -08:00
|
|
|
build.run(&mut cargo);
|
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the tools to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full and using more cores for the work
at hand. Additionally the architecture here should be a bit speedier as it
should have less overhead than adb which is a whole new process on both the host
and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfully that test suite is much smaller than the run-pass test
suite.
As a final fix I discovered that the ARM and Android test suites were actually
running all library unit tests (e.g. stdtest, coretest, etc) twice. I've
corrected that to only run tests once which should also give a nice boost in
overall cycle time here.
2017-04-26 08:52:19 -07:00
|
|
|
krate_remote(build, &compiler, target, mode);
|
2016-06-28 13:31:30 -07:00
|
|
|
} else {
|
2016-10-21 13:18:09 -07:00
|
|
|
cargo.args(&build.flags.cmd.test_args());
|
2016-06-28 13:31:30 -07:00
|
|
|
build.run(&mut cargo);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-09-06 00:41:50 +00:00
|
|
|
fn krate_emscripten(build: &Build,
|
|
|
|
compiler: &Compiler,
|
|
|
|
target: &str,
|
|
|
|
mode: Mode) {
|
2017-01-28 13:38:06 -08:00
|
|
|
let mut tests = Vec::new();
|
|
|
|
let out_dir = build.cargo_out(compiler, mode, target);
|
|
|
|
find_tests(&out_dir.join("deps"), target, &mut tests);
|
|
|
|
|
|
|
|
for test in tests {
|
|
|
|
let test_file_name = test.to_string_lossy().into_owned();
|
|
|
|
println!("running {}", test_file_name);
|
|
|
|
let nodejs = build.config.nodejs.as_ref().expect("nodejs not configured");
|
|
|
|
let mut cmd = Command::new(nodejs);
|
|
|
|
cmd.arg(&test_file_name);
|
|
|
|
if build.config.quiet_tests {
|
|
|
|
cmd.arg("--quiet");
|
|
|
|
}
|
|
|
|
build.run(&mut cmd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the tools to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full and using more cores for the work
at hand. Additionally the architecture here should be a bit speedier as it
should have less overhead than adb which is a whole new process on both the host
and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfully that test suite is much smaller than the run-pass test
suite.
As a final fix I discovered that the ARM and Android test suites were actually
running all library unit tests (e.g. stdtest, coretest, etc) twice. I've
corrected that to only run tests once which should also give a nice boost in
overall cycle time here.
2017-04-26 08:52:19 -07:00
|
|
|
fn krate_remote(build: &Build,
|
|
|
|
compiler: &Compiler,
|
|
|
|
target: &str,
|
|
|
|
mode: Mode) {
|
2017-01-28 13:38:06 -08:00
|
|
|
let mut tests = Vec::new();
|
|
|
|
let out_dir = build.cargo_out(compiler, mode, target);
|
|
|
|
find_tests(&out_dir.join("deps"), target, &mut tests);
|
|
|
|
|
|
|
|
let tool = build.tool(&Compiler::new(0, &build.config.build),
|
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the tools to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full and using more cores for the work
at hand. Additionally the architecture here should be a bit speedier as it
should have less overhead than adb which is a whole new process on both the host
and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfully that test suite is much smaller than the run-pass test
suite.
As a final fix I discovered that the ARM and Android test suites were actually
running all library unit tests (e.g. stdtest, coretest, etc) twice. I've
corrected that to only run tests once which should also give a nice boost in
overall cycle time here.
2017-04-26 08:52:19 -07:00
|
|
|
"remote-test-client");
|
2017-01-28 13:38:06 -08:00
|
|
|
for test in tests {
|
|
|
|
let mut cmd = Command::new(&tool);
|
|
|
|
cmd.arg("run")
|
|
|
|
.arg(&test);
|
|
|
|
if build.config.quiet_tests {
|
|
|
|
cmd.arg("--quiet");
|
|
|
|
}
|
|
|
|
cmd.args(&build.flags.cmd.test_args());
|
|
|
|
build.run(&mut cmd);
|
|
|
|
}
|
|
|
|
}
|
2016-09-05 19:56:48 -04:00
|
|
|
|
2016-06-28 13:31:30 -07:00
|
|
|
fn find_tests(dir: &Path,
|
|
|
|
target: &str,
|
|
|
|
dst: &mut Vec<PathBuf>) {
|
|
|
|
for e in t!(dir.read_dir()).map(|e| t!(e)) {
|
|
|
|
let file_type = t!(e.file_type());
|
|
|
|
if !file_type.is_file() {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
let filename = e.file_name().into_string().unwrap();
|
|
|
|
if (target.contains("windows") && filename.ends_with(".exe")) ||
|
2016-09-05 19:56:48 -04:00
|
|
|
(!target.contains("windows") && !filename.contains(".")) ||
|
2017-03-04 14:59:49 +01:00
|
|
|
(target.contains("emscripten") && filename.ends_with(".js")) {
|
2016-06-28 13:31:30 -07:00
|
|
|
dst.push(e.path());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-11 12:10:05 +02:00
|
|
|
pub fn remote_copy_libs(build: &Build, compiler: &Compiler, target: &str) {
|
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the tools to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full and using more cores for the work
at hand. Additionally the architecture here should be a bit speedier as it
should have less overhead than adb which is a whole new process on both the host
and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfully that test suite is much smaller than the run-pass test
suite.
As a final fix I discovered that the ARM and Android test suites were actually
running all library unit tests (e.g. stdtest, coretest, etc) twice. I've
corrected that to only run tests once which should also give a nice boost in
overall cycle time here.
2017-04-26 08:52:19 -07:00
|
|
|
if !build.remote_tested(target) {
|
|
|
|
return
|
2016-06-28 13:31:30 -07:00
|
|
|
}
|
2016-12-08 17:13:55 -08:00
|
|
|
|
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the tools to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full and using more cores for the work
at hand. Additionally the architecture here should be a bit speedier as it
should have less overhead than adb which is a whole new process on both the host
and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfully that test suite is much smaller than the run-pass test
suite.
As a final fix I discovered that the ARM and Android test suites were actually
running all library unit tests (e.g. stdtest, coretest, etc) twice. I've
corrected that to only run tests once which should also give a nice boost in
overall cycle time here.
2017-04-26 08:52:19 -07:00
|
|
|
println!("REMOTE copy libs to emulator ({})", target);
|
2017-01-28 13:38:06 -08:00
|
|
|
t!(fs::create_dir_all(build.out.join("tmp")));
|
|
|
|
|
|
|
|
let server = build.cargo_out(compiler, Mode::Tool, target)
|
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the tools to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full and using more cores for the work
at hand. Additionally the architecture here should be a bit speedier as it
should have less overhead than adb which is a whole new process on both the host
and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfully that test suite is much smaller than the run-pass test
suite.
As a final fix I discovered that the ARM and Android test suites were actually
running all library unit tests (e.g. stdtest, coretest, etc) twice. I've
corrected that to only run tests once which should also give a nice boost in
overall cycle time here.
2017-04-26 08:52:19 -07:00
|
|
|
.join(exe("remote-test-server", target));
|
2017-01-28 13:38:06 -08:00
|
|
|
|
|
|
|
// Spawn the emulator and wait for it to come online
|
|
|
|
let tool = build.tool(&Compiler::new(0, &build.config.build),
|
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the tools to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full and using more cores for the work
at hand. Additionally the architecture here should be a bit speedier as it
should have less overhead than adb which is a whole new process on both the host
and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfully that test suite is much smaller than the run-pass test
suite.
As a final fix I discovered that the ARM and Android test suites were actually
running all library unit tests (e.g. stdtest, coretest, etc) twice. I've
corrected that to only run tests once which should also give a nice boost in
overall cycle time here.
2017-04-26 08:52:19 -07:00
|
|
|
"remote-test-client");
|
|
|
|
let mut cmd = Command::new(&tool);
|
|
|
|
cmd.arg("spawn-emulator")
|
|
|
|
.arg(target)
|
|
|
|
.arg(&server)
|
|
|
|
.arg(build.out.join("tmp"));
|
|
|
|
if let Some(rootfs) = build.qemu_rootfs(target) {
|
|
|
|
cmd.arg(rootfs);
|
|
|
|
}
|
|
|
|
build.run(&mut cmd);
|
2017-01-28 13:38:06 -08:00
|
|
|
|
|
|
|
// Push all our dylibs to the emulator
|
|
|
|
for f in t!(build.sysroot_libdir(compiler, target).read_dir()) {
|
|
|
|
let f = t!(f);
|
|
|
|
let name = f.file_name().into_string().unwrap();
|
|
|
|
if util::is_dylib(&name) {
|
|
|
|
build.run(Command::new(&tool)
|
|
|
|
.arg("push")
|
|
|
|
.arg(f.path()));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-08 17:13:55 -08:00
|
|
|
/// Run "distcheck", a 'make check' from a tarball
|
|
|
|
pub fn distcheck(build: &Build) {
|
|
|
|
if build.config.build != "x86_64-unknown-linux-gnu" {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
if !build.config.host.iter().any(|s| s == "x86_64-unknown-linux-gnu") {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
if !build.config.target.iter().any(|s| s == "x86_64-unknown-linux-gnu") {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2017-04-26 12:37:12 -07:00
|
|
|
println!("Distcheck");
|
2016-12-08 17:13:55 -08:00
|
|
|
let dir = build.out.join("tmp").join("distcheck");
|
|
|
|
let _ = fs::remove_dir_all(&dir);
|
|
|
|
t!(fs::create_dir_all(&dir));
|
|
|
|
|
|
|
|
let mut cmd = Command::new("tar");
|
|
|
|
cmd.arg("-xzf")
|
|
|
|
.arg(dist::rust_src_location(build))
|
|
|
|
.arg("--strip-components=1")
|
|
|
|
.current_dir(&dir);
|
|
|
|
build.run(&mut cmd);
|
|
|
|
build.run(Command::new("./configure")
|
2016-12-30 09:26:25 -08:00
|
|
|
.args(&build.config.configure_args)
|
2017-02-10 22:59:40 +02:00
|
|
|
.arg("--enable-vendor")
|
2016-12-08 17:13:55 -08:00
|
|
|
.current_dir(&dir));
|
2016-12-17 20:09:23 +01:00
|
|
|
build.run(Command::new(build_helper::make(&build.config.build))
|
2016-12-08 17:13:55 -08:00
|
|
|
.arg("check")
|
|
|
|
.current_dir(&dir));
|
2017-04-26 12:37:12 -07:00
|
|
|
|
|
|
|
// Now make sure that rust-src has all of libstd's dependencies
|
|
|
|
println!("Distcheck rust-src");
|
|
|
|
let dir = build.out.join("tmp").join("distcheck-src");
|
|
|
|
let _ = fs::remove_dir_all(&dir);
|
|
|
|
t!(fs::create_dir_all(&dir));
|
|
|
|
|
|
|
|
let mut cmd = Command::new("tar");
|
|
|
|
cmd.arg("-xzf")
|
|
|
|
.arg(dist::rust_src_installer(build))
|
|
|
|
.arg("--strip-components=1")
|
|
|
|
.current_dir(&dir);
|
|
|
|
build.run(&mut cmd);
|
|
|
|
|
|
|
|
let toml = dir.join("rust-src/lib/rustlib/src/rust/src/libstd/Cargo.toml");
|
|
|
|
build.run(Command::new(&build.cargo)
|
|
|
|
.arg("generate-lockfile")
|
|
|
|
.arg("--manifest-path")
|
|
|
|
.arg(&toml)
|
|
|
|
.current_dir(&dir));
|
2016-12-08 17:13:55 -08:00
|
|
|
}
|
2016-12-30 19:50:57 -08:00
|
|
|
|
|
|
|
/// Test the build system itself
|
|
|
|
pub fn bootstrap(build: &Build) {
|
|
|
|
let mut cmd = Command::new(&build.cargo);
|
|
|
|
cmd.arg("test")
|
|
|
|
.current_dir(build.src.join("src/bootstrap"))
|
|
|
|
.env("CARGO_TARGET_DIR", build.out.join("bootstrap"))
|
|
|
|
.env("RUSTC", &build.rustc);
|
|
|
|
cmd.arg("--").args(&build.flags.cmd.test_args());
|
|
|
|
build.run(&mut cmd);
|
|
|
|
}
|