rust/src/bootstrap
bors 483fc715c6 Auto merge of #32239 - alexcrichton:fix-cross-to-freebsd, r=brson
rustbuild: Fix cross compiling to FreeBSD

This commit fixes our support for cross compiling a compiler to run on FreeBSD.
Over the weekend I managed to get a cross compiler from Linux to FreeBSD [1]
which I hope to soon use to start producing FreeBSD nightly compilers. With the
`make dist` support added in #32237 we should be able to produce standard
rustc/rust-std packages for FreeBSD through a new slave with this cross compiler.

Currently, however, we don't "Just Work" when cross compiling FreeBSD and a
number of changes were required (part of this PR). They include:

* A few build fixes were needed in LLVM. Our own branch has been rebased on the
  actual 3.8 release and I applied one extra commit [2] which contains two fixes:

  1. The LLVM CMake build system passes the `-Wl,-z,defs` flag on many
     platforms, but *not* when `CMAKE_SYSTEM_NAME` is "FreeBSD". Unfortunately
     this doesn't take into account when we're cross compiling, and as predicted
     the build will fail if `-Wl,-z,defs` is passed (see [3] for more info). To
     fix this we test `TARGET_TRIPLE` instead of the `CMAKE_SYSTEM_NAME` which
     is what we're compiling for which fixes the problem.
  2. The `PATH_MAX` constant is apparently defined in a different location than
     many other Unix systems, so a file which required this just needed some
     help to keep compiling.

* Support for compiling compiler-rt with CMake has been added to rustbuild. It
  looks like it just emulates Linux in what it compiles as it didn't seem to
  naturally produce anything else... At least the architecture is right, so
  seems good for now at least!

[1]: https://github.com/alexcrichton/port-of-rust/blob/master/prebuilt/freebsd/Dockerfile
[2]: be89e4b5
[3]: https://bugs.webkit.org/show_bug.cgi?id=138420
2016-03-15 03:21:40 -07:00
..
build Auto merge of #32239 - alexcrichton:fix-cross-to-freebsd, r=brson 2016-03-15 03:21:40 -07:00
mk rustbuild: Add make check and a check target 2016-03-07 22:50:55 -08:00
bootstrap.py rustbuild: Add a link checker for documentation 2016-03-08 13:44:14 -08:00
Cargo.lock rustbuild: Update dependencies 2016-02-28 10:50:13 -08:00
Cargo.toml rustbuild: Fixup calling rustdoc in various stages 2016-03-08 11:52:11 -08:00
lib.rs Add a Cargo-based build system 2016-02-11 10:42:28 -08:00
main.rs Add a Cargo-based build system 2016-02-11 10:42:28 -08:00
README.md Add a Cargo-based build system 2016-02-11 10:42:28 -08:00
rustc.rs rustbuild: Fixup calling rustdoc in various stages 2016-03-08 11:52:11 -08:00
rustdoc.rs rustbuild: Fixup calling rustdoc in various stages 2016-03-08 11:52:11 -08:00

Bootstrapping Rust

This is an in-progress README which is targeted at helping to explain how Rust is bootstrapped and in general some of the technical details of the build system.

Note

intended to be the primarily used one just yet. The makefiles are currently the ones that are still "guaranteed to work" as much as possible at least.

Using the new build system

When configuring Rust via ./configure, pass the following to enable building via this build system:

./configure --enable-rustbuild

...

Directory Layout

This build system houses all output under the target directory, which looks like this:

# Root folder of all output. Everything is scoped underneath here
build/

  # Location where the stage0 compiler downloads are all cached. This directory
  # only contains the tarballs themselves as they're extracted elsewhere.
  cache/
    2015-12-19/
    2016-01-15/
    2016-01-21/
    ...

  # Output directory for building this build system itself. The stage0
  # cargo/rustc are used to build the build system into this location.
  bootstrap/
    debug/
    release/

  # Each remaining directory is scoped by the "host" triple of compilation at
  # hand.
  x86_64-unknown-linux-gnu/

    # The build artifacts for the `compiler-rt` library for the target this
    # folder is under. The exact layout here will likely depend on the platform,
    # and this is also built with CMake so the build system is also likely
    # different.
    compiler-rt/build/

    # Output folder for LLVM if it is compiled for this target
    llvm/

      # build folder (e.g. the platform-specific build system). Like with
      # compiler-rt this is compiled with CMake
      build/

      # Installation of LLVM. Note that we run the equivalent of 'make install'
      # for LLVM to setup these folders.
      bin/
      lib/
      include/
      share/
      ...

    # Location where the stage0 Cargo and Rust compiler are unpacked. This
    # directory is purely an extracted and overlaid tarball of these two (done
    # by the bootstrapy python script). In theory the build system does not
    # modify anything under this directory afterwards.
    stage0/

    # These to build directories are the cargo output directories for builds of
    # the standard library and compiler, respectively. Internally these may also
    # have other target directories, which represent artifacts being compiled
    # from the host to the specified target.
    #
    # Essentially, each of these directories is filled in by one `cargo`
    # invocation. The build system instruments calling Cargo in the right order
    # with the right variables to ensure these are filled in correctly.
    stageN-std/
    stageN-rustc/

    # This is a special case of the above directories, **not** filled in via
    # Cargo but rather the build system itself. The stage0 compiler already has
    # a set of target libraries for its own host triple (in its own sysroot)
    # inside of stage0/. When we run the stage0 compiler to bootstrap more
    # things, however, we don't want to use any of these libraries (as those are
    # the ones that we're building). So essentially, when the stage1 compiler is
    # being compiled (e.g. after libstd has been built), *this* is used as the
    # sysroot for the stage0 compiler being run.
    #
    # Basically this directory is just a temporary artifact use to configure the
    # stage0 compiler to ensure that the libstd we just built is used to
    # compile the stage1 compiler.
    stage0-rustc/lib/

    # These output directories are intended to be standalone working
    # implementations of the compiler (corresponding to each stage). The build
    # system will link (using hard links) output from stageN-{std,rustc} into
    # each of these directories.
    #
    # In theory there is no extra build output in these directories.
    stage1/
    stage2/
    stage3/