1. 28 Aug, 2017 1 commit
    • Alex Crichton's avatar
      rustbuild: Rewrite the configure script in Python · a9b0a7ba
      Alex Crichton authored
      This commit rewrites our ancient `./configure` script from shell into Python.
      The impetus for this change is to remove `config.mk` which is just a vestige of
      the old makefile build system at this point. Instead all configuration is now
      solely done through `config.toml`.
      The python script allows us to more flexibly program (aka we can use loops
      easily) and create a `config.toml` which is based off `config.toml.example`.
      This way we can preserve comments and munge various values as we see fit.
      It is intended that the configure script here is a drop-in replacement for the
      previous configure script, no functional change is intended. Also note that the
      rationale for this is also because our build system requires Python, so having a
      python script a bit earlier shouldn't cause too many problems.
      Closes #40730
  2. 30 Jul, 2017 1 commit
  3. 24 Jul, 2017 1 commit
    • Alex Crichton's avatar
      Add a disabled builder for aarch64 emulated tests · 8ef3f69f
      Alex Crichton authored
      This commit adds a disabled builder which will run all tests for the standard
      library for aarch64 in a QEMU instance. Once we get enough capacity to run this
      on Travis this can be used to boost our platform coverage of AArch64
  4. 17 Jul, 2017 1 commit
  5. 23 Jun, 2017 1 commit
    • Thomas Lively's avatar
      Make wasm32 buildbot test LLVM backend · 447297ce
      Thomas Lively authored
      This adds the experimental targets option to configure so it can be used
      by the builders and changes the wasm32 Dockerfile accordingly. Instead
      of using LLVM from the emsdk, the builder's emscripten tools now uses
      the Rust in-tree LLVM, since this is the one built with wasm support.
  6. 16 May, 2017 1 commit
  7. 02 May, 2017 1 commit
    • Ralph Giles's avatar
      Remove obsolete --disable-elf-tls configure switch. · 19cab639
      Ralph Giles authored
      Support for disabling ELF-style thread local storage in
      the standard library at configure time was removed in
      pulls #30417 and #30678, in favour of a member in
      the TargetOptions database. The new method respects
      MACOSX_DEPLOYMENT_TARGET on macOS, addressing the
      original use case for this configure option.
      However, those commits left the configure option itself
      in place. It's no longer referenced anywhere and can
      be removed.
  8. 01 May, 2017 1 commit
    • whitequark's avatar
      Add profiling support, through the rustc -Z profile flag. · 42754ce7
      whitequark authored
      When -Z profile is passed, the GCDAProfiling LLVM pass is added
      to the pipeline, which uses debug information to instrument the IR.
      After compiling with -Z profile, the $(OUT_DIR)/$(CRATE_NAME).gcno
      file is created, containing initial profiling information.
      After running the program built, the $(OUT_DIR)/$(CRATE_NAME).gcda
      file is created, containing branch counters.
      The created *.gcno and *.gcda files can be processed using
      the "llvm-cov gcov" and "lcov" tools. The profiling data LLVM
      generates does not faithfully follow the GCC's format for *.gcno
      and *.gcda files, and so it will probably not work with other tools
      (such as gcov itself) that consume these files.
  9. 20 Apr, 2017 1 commit
  10. 09 Apr, 2017 1 commit
  11. 12 Mar, 2017 1 commit
  12. 11 Mar, 2017 8 commits
  13. 10 Mar, 2017 1 commit
  14. 03 Mar, 2017 1 commit
    • Alex Crichton's avatar
      rustbuild: Add support for compiling Cargo · 44a01b8a
      Alex Crichton authored
      This commit adds support to rustbuild for compiling Cargo as part of the release
      process. Previously rustbuild would simply download a Cargo snapshot and
      repackage it. With this change we should be able to turn off artifacts from the
      rust-lang/cargo repository and purely rely on the artifacts Cargo produces here.
      The infrastructure added here is intended to be extensible to other components,
      such as the RLS. It won't exactly be a one-line addition, but the addition of
      Cargo didn't require too much hooplah anyway.
      The process for release Cargo will now look like:
      * The rust-lang/rust repository has a Cargo submodule which is used to build a
        Cargo to pair with the rust-lang/rust release
      * Periodically we'll update the cargo submodule as necessary on rust-lang/rust's
        master branch
      * When branching beta we'll create a new branch of Cargo (as we do today), and
        the first commit to the beta branch will be to update the Cargo submodule to
        this exact revision.
      * When branching stable, we'll ensure that the Cargo submodule is updated and
        then make a stable release.
      Backports to Cargo will look like:
      * Send a PR to cargo's master branch
      * Send a PR to cargo's release branch (e.g. rust-1.16.0)
      * Send a PR to rust-lang/rust's beta branch updating the submodule
      * Eventually send a PR to rust-lang/rust's master branch updating the submodule
      For reference, the process to add a new component to the rust-lang/rust release
      would look like:
      * Add `$foo` as a submodule in `src/tools`
      * Add a `tool-$foo` step which compiles `$foo` with the specified compiler,
        likely mirroring what Cargo does.
      * Add a `dist-$foo` step which uses `src/tools/$foo` and the `tool-$foo` output
        to create a rust-installer package for `$foo` likely mirroring what Cargo
      * Update the `dist-extended` step with a new dependency on `dist-$foo`
      * Update `src/tools/build-manifest` for the new component.
  15. 16 Feb, 2017 1 commit
    • Alex Crichton's avatar
      travis: Disable source tarballs on most builders · 19024882
      Alex Crichton authored
      Currently we create a source tarball on almost all of the `DEPLOY=1` builders
      but this has the adverse side effect of all source tarballs overriding
      themselves in the S3 bucket. Normally this is ok but unfortunately a source
      tarball created on Windows is not buildable on Unix.
      On Windows the vendored sources contain paths with `\` characters in them which
      when interpreted on Unix end up in "file not found" errors.
      Instead of this overwriting behavior, whitelist just one linux builder for
      producing tarballs and avoid producing tarballs on all other hosts.
  16. 13 Feb, 2017 2 commits
  17. 08 Feb, 2017 1 commit
  18. 06 Feb, 2017 1 commit
  19. 03 Feb, 2017 1 commit
  20. 29 Jan, 2017 1 commit
    • Alex Crichton's avatar
      Add support for test suites emulated in QEMU · 1747ce25
      Alex Crichton authored
      This commit adds support to the build system to execute test suites that cannot
      run natively but can instead run inside of a QEMU emulator. A proof-of-concept
      builder was added for the `arm-unknown-linux-gnueabihf` target to show off how
      this might work.
      In general the architecture is to have a server running inside of the emulator
      which a local client connects to. The protocol between the server/client
      supports compiling tests on the host and running them on the target inside the
      Closes #33114
  21. 24 Jan, 2017 1 commit
    • Alex Crichton's avatar
      rustbuild: Start building --enable-extended · f3dfcae2
      Alex Crichton authored
      This commit adds a new flag to the configure script,
      `--enable-extended`, which is intended for specifying a desire to
      compile the full suite of Rust tools such as Cargo, the RLS, etc. This
      is also an indication that the build system should create combined
      installers such as the pkg/exe/msi artifacts.
      Currently the `--enable-extended` flag just indicates that combined
      installers should be built, and Cargo is itself not compiled just yet
      but rather only downloaded from its location. The intention here is to
      quickly get to feature parity with the current release process and then
      we can start improving it afterwards.
      All new files in this PR inside `src/etc/installer` are copied from the
      rust-packaging repository.
  22. 17 Jan, 2017 1 commit
    • Alex Crichton's avatar
      travis: Pass --release-channel=nightly on deploy · 06185802
      Alex Crichton authored
      This commit passes the `--release-channel=nightly` flag to all images which have
      the `DEPLOY` flag set. This means that we'll name artifacts and the compiler
      This reworks a bit how arguments are passed, but for now doesn't change what's
      already being passed. Eventually we'll want to avoid enabling debug assertions
      and llvm assertions for *all* releases, but I figure we can tackle that a little
      bit more down the road.
  23. 12 Jan, 2017 1 commit
  24. 11 Jan, 2017 1 commit
    • Alex Crichton's avatar
      rustbuild: Don't enable debuginfo in rustc · 099e7cb1
      Alex Crichton authored
      In #37280 we enabled line number debugging information in release artifacts,
      primarily to close out #36452 where debugging information was critical for MSVC
      builds of Rust to be useful in production. This commit, however, apparently had
      some unfortunate side effects.
      Namely it was noticed in #37477 that if `RUST_BACKTRACE=1` was set then any
      compiler error would take a very long time for the compiler to exit. The cause
      of the problem here was somewhat deep:
      * For all compiler errors, the compiler will `panic!` with a known value. This
        tears down the main compiler thread and allows cleaning up all the various
        resources. By default, however, this panic output is suppressed for "normal"
        compiler errors.
      * When `RUST_BACKTRACE=1` was set this caused every compiler error to generate a
      * The libbacktrace library hits a pathological case where it spends a very long
        time in its custom allocation function, `backtrace_alloc`, because the
        compiler has so much debugging information. More information about this can be
        found in #29293 with a summary at the end of #37477.
      To solve this problem this commit simply removes debuginfo from the compiler but
      not from the standard library. This should allow us to keep #36452 closed while
      also closing #37477. I've measured the difference to be orders of magnitude
      faster than it was before, so we should see a much quicker time-to-exit after a
      compile error when `RUST_BACKTRACE=1` is set.
      Closes #37477
      Closes #37571
  25. 02 Jan, 2017 1 commit
  26. 30 Dec, 2016 1 commit
  27. 28 Dec, 2016 1 commit
    • Alex Crichton's avatar
      rustbuild: Compile rustc twice, not thrice · 7046fea5
      Alex Crichton authored
      This commit switches the rustbuild build system to compiling the
      compiler twice for a normal bootstrap rather than the historical three
      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
      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:
          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.
  28. 22 Dec, 2016 1 commit
  29. 14 Dec, 2016 1 commit
    • Alex Crichton's avatar
      rustbuild: Add sccache support · 96a5fc76
      Alex Crichton authored
      This commit adds support for sccache, a ccache-like compiler which works on MSVC
      and stores results into an S3 bucket. This also switches over all Travis and
      AppVeyor automation to using sccache to ensure a shared and unified cache over
      time which can be shared across builders.
      The support for sccache manifests as a new `--enable-sccache` option which
      instructs us to configure LLVM differently to use a 'sccache' binary instead of
      a 'ccache' binary. All docker images for Travis builds are updated to download
      Mozilla's tooltool builds of sccache onto various containers and systems.
      Additionally a new `rust-lang-ci-sccache` bucket is configured to hold all of
      our ccache goodies.
  30. 08 Dec, 2016 1 commit
  31. 07 Dec, 2016 1 commit
  32. 02 Dec, 2016 1 commit