1. 03 Nov, 2016 1 commit
    • Alex Crichton's avatar
      rustbuild: Rewrite user-facing interface · a270b801
      Alex Crichton authored
      This commit is a rewrite of the user-facing interface to the rustbuild build
      system. The intention here is to make it much easier to compile/test the project
      without having to remember weird rule names and such. An overall view of the new
      interface is:
          # build everything
          ./x.py build
          # document everyting
          ./x.py doc
          # test everything
          ./x.py test
          # test libstd
          ./x.py test src/libstd
          # build libcore stage0
          ./x.py build src/libcore --stage 0
          # run stage1 run-pass tests
          ./x.py test src/test/run-pass --stage 1
      The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py`
      script. This `x` was chosen to be both short and easily tab-completable (no
      collisions in that namespace!). The build system now accepts a "subcommand" of
      what to do next, the main ones being build/doc/test.
      Each subcommand then receives an optional list of arguments. These arguments are
      paths in the source repo of what to work with. That is, if you want to test a
      directory, you just pass that directory as an argument.
      The purpose of this rewrite is to do away with all of the arcane renames like
      "rpass" is the "run-pass" suite, "cfail" is the "compile-fail" suite, etc. By
      simply working with directories and files it's much more intuitive of how to run
      a test (just pass it as an argument).
      The rustbuild step/dependency management was also rewritten along the way to
      make this easy to work with and define, but that's largely just a refactoring of
      what was there before.
      The *intention* is that this support is extended for arbitrary files (e.g.
      `src/test/run-pass/my-test-case.rs`), but that isn't quite implemented just yet.
      Instead directories work for now but we can follow up with stricter path
      filtering logic to plumb through all the arguments.
  2. 14 Feb, 2016 1 commit
    • Alex Crichton's avatar
      trans: Don't link whole rlibs to executables · cc719d2d
      Alex Crichton authored
      Back in 9bc8e6d1 the linking of rlibs changed to using the `link_whole_rlib`
      function. This change, however was only intended to affect dylibs, not
      executables. For executables we don't actually want to link entire rlibs because
      we want the linker to strip out as much as possible.
      This commit adds a conditional to this logic to only link entire rlibs if we're
      creating a dylib, and otherwise an executable just links an rlib as usual. A
      test is included which will fail to link if this behavior is reverted.
  3. 12 Jun, 2015 1 commit
    • Ulrik Sverdrup's avatar
      mk: Build crates with relative paths to rustc · 70269cd8
      Ulrik Sverdrup authored
      The path we pass to rustc will be visible in panic messages and
      backtraces: they will be user visible!
      Avoid junk in these paths by passing relative paths to rustc.
      For most advanced users, `libcore` or `libstd` in the path will be
      a clue to the location -- inside our code, not theirs.
      Store both the relative path to the source as well as the absolute.
      Use the relative path where it matters, compiling the main crates,
      instead of changing all of the build process to cope with relative
      Example output after this patch:
      $ ./testunwrap
      thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362
      $ RUST_BACKTRACE=1 ./testunwrap
      thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362
      stack backtrace:
         1:     0x7ff59c1e9956 - sys::backtrace::write::h67a542fd2b201576des
                              at ../src/libstd/sys/unix/backtrace.rs:158
         2:     0x7ff59c1ed5b6 - panicking::on_panic::h3d21c41cdd5c12d41Xw
                              at ../src/libstd/panicking.rs:58
         3:     0x7ff59c1e7b6e - rt::unwind::begin_unwind_inner::h9f3a5440cebb8baeLDw
                              at ../src/libstd/rt/unwind/mod.rs:273
         4:     0x7ff59c1e7f84 - rt::unwind::begin_unwind_fmt::h4fe8a903e0c296b0RCw
                              at ../src/libstd/rt/unwind/mod.rs:212
         5:     0x7ff59c1eced7 - rust_begin_unwind
         6:     0x7ff59c22c11a - panicking::panic_fmt::h00b0cd49c98a9220i5B
                              at ../src/libcore/panicking.rs:64
         7:     0x7ff59c22b9e0 - panicking::panic::hf549420c0ee03339P3B
                              at ../src/libcore/panicking.rs:45
         8:     0x7ff59c1e621d - option::Option<T>::unwrap::h501963526474862829
         9:     0x7ff59c1e61b1 - main::hb5c91ce92347d1e6eaa
        10:     0x7ff59c1f1c18 - rust_try_inner
        11:     0x7ff59c1f1c05 - rust_try
        12:     0x7ff59c1ef374 - rt::lang_start::h7e51e19c6677cffe5Sw
                              at ../src/libstd/rt/unwind/mod.rs:147
                              at ../src/libstd/rt/unwind/mod.rs:130
                              at ../src/libstd/rt/mod.rs:128
        13:     0x7ff59c1e628e - main
        14:     0x7ff59b3f6b44 - __libc_start_main
        15:     0x7ff59c1e6078 - <unknown>
        16:                0x0 - <unknown>
  4. 11 Apr, 2015 1 commit
  5. 15 Mar, 2015 1 commit
  6. 15 Feb, 2014 2 commits
  7. 05 Feb, 2014 1 commit
  8. 19 Jul, 2013 1 commit
  9. 18 Jan, 2013 1 commit
  10. 07 Dec, 2011 1 commit
  11. 02 Dec, 2011 1 commit
  12. 29 Nov, 2011 1 commit
  13. 12 May, 2011 1 commit
  14. 03 May, 2011 3 commits