2016-05-02 22:16:15 +00:00
|
|
|
# Sample TOML configuration file for building Rust.
|
|
|
|
#
|
2023-03-02 07:48:31 +00:00
|
|
|
# To configure rustbuild, run `./configure` or `./x.py setup`.
|
|
|
|
# See https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html#create-a-configtoml for more information.
|
2016-09-02 23:54:02 +00:00
|
|
|
#
|
2016-05-02 22:16:15 +00:00
|
|
|
# All options are commented out by default in this file, and they're commented
|
|
|
|
# out with their default values. The build system by default looks for
|
|
|
|
# `config.toml` in the current directory of a build for build configuration, but
|
|
|
|
# a custom configuration file can also be specified with `--config` to the build
|
|
|
|
# system.
|
|
|
|
|
2020-09-12 04:42:52 +00:00
|
|
|
# =============================================================================
|
|
|
|
# Global Settings
|
|
|
|
# =============================================================================
|
|
|
|
|
|
|
|
# Use different pre-set defaults than the global defaults.
|
|
|
|
#
|
|
|
|
# See `src/bootstrap/defaults` for more information.
|
2023-04-08 08:19:00 +00:00
|
|
|
# Note that this has no default value (x.py uses the defaults in `config.example.toml`).
|
2020-09-12 04:42:52 +00:00
|
|
|
#profile = <none>
|
|
|
|
|
2023-10-01 13:54:52 +00:00
|
|
|
# Keeps track of major changes made to this configuration.
|
|
|
|
#
|
|
|
|
# This value also represents ID of the PR that caused major changes. Meaning,
|
|
|
|
# you can visit github.com/rust-lang/rust/pull/{change-id} to check for more details.
|
|
|
|
#
|
|
|
|
# A 'major change' includes any of the following
|
|
|
|
# - A new option
|
|
|
|
# - A change in the default values
|
|
|
|
#
|
|
|
|
# If `change-id` does not match the version that is currently running,
|
|
|
|
# `x.py` will prompt you to update it and check the related PR for more details.
|
2023-10-31 08:52:16 +00:00
|
|
|
change-id = 117435
|
2023-03-02 07:48:31 +00:00
|
|
|
|
2016-05-02 22:16:15 +00:00
|
|
|
# =============================================================================
|
|
|
|
# Tweaking how LLVM is compiled
|
|
|
|
# =============================================================================
|
|
|
|
[llvm]
|
|
|
|
|
2020-09-04 23:00:04 +00:00
|
|
|
# Whether to use Rust CI built LLVM instead of locally building it.
|
|
|
|
#
|
|
|
|
# Unless you're developing for a target where Rust CI doesn't build a compiler
|
2023-03-02 07:48:31 +00:00
|
|
|
# toolchain or changing LLVM locally, you probably want to leave this enabled.
|
2020-09-04 23:00:04 +00:00
|
|
|
#
|
2021-07-14 13:50:38 +00:00
|
|
|
# All tier 1 targets are currently supported; set this to `"if-available"` if
|
2021-01-13 14:32:48 +00:00
|
|
|
# you are not sure whether you're on a tier 1 target.
|
2020-09-04 23:00:04 +00:00
|
|
|
#
|
|
|
|
# We also currently only support this when building LLVM for the build triple.
|
|
|
|
#
|
|
|
|
# Note that many of the LLVM options are not currently supported for
|
|
|
|
# downloading. Currently only the "assertions" option can be toggled.
|
2023-03-02 07:48:31 +00:00
|
|
|
#download-ci-llvm = if rust.channel == "dev" { "if-available" } else { false }
|
2020-09-04 23:00:04 +00:00
|
|
|
|
2016-05-02 22:16:15 +00:00
|
|
|
# Indicates whether the LLVM build is a Release or Debug build
|
|
|
|
#optimize = true
|
|
|
|
|
2018-08-10 10:23:48 +00:00
|
|
|
# Indicates whether LLVM should be built with ThinLTO. Note that this will
|
|
|
|
# only succeed if you use clang, lld, llvm-ar, and llvm-ranlib in your C/C++
|
|
|
|
# toolchain (see the `cc`, `cxx`, `linker`, `ar`, and `ranlib` options below).
|
|
|
|
# More info at: https://clang.llvm.org/docs/ThinLTO.html#clang-bootstrap
|
|
|
|
#thin-lto = false
|
|
|
|
|
2016-11-10 16:30:06 +00:00
|
|
|
# Indicates whether an LLVM Release build should include debug info
|
|
|
|
#release-debuginfo = false
|
|
|
|
|
2016-05-02 22:16:15 +00:00
|
|
|
# Indicates whether the LLVM assertions are enabled or not
|
2023-03-02 07:48:31 +00:00
|
|
|
# NOTE: When assertions are disabled, bugs in the integration between rustc and LLVM can lead to
|
|
|
|
# unsoundness (segfaults, etc.) in the rustc process itself, not just in the generated code.
|
2016-05-02 22:16:15 +00:00
|
|
|
#assertions = false
|
|
|
|
|
2021-10-18 21:59:00 +00:00
|
|
|
# Indicates whether the LLVM testsuite is enabled in the build or not. Does
|
|
|
|
# not execute the tests as part of the build as part of x.py build et al,
|
|
|
|
# just makes it possible to do `ninja check-llvm` in the staged LLVM build
|
|
|
|
# directory when doing LLVM development as part of Rust development.
|
|
|
|
#tests = false
|
|
|
|
|
2021-07-20 00:38:39 +00:00
|
|
|
# Indicates whether the LLVM plugin is enabled or not
|
|
|
|
#plugins = false
|
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Indicates whether ccache is used when building LLVM. Set to `true` to use the first `ccache` in
|
|
|
|
# PATH, or set an absolute path to use a specific version.
|
2016-05-02 22:16:15 +00:00
|
|
|
#ccache = false
|
|
|
|
|
2022-11-09 22:26:25 +00:00
|
|
|
# When true, link libstdc++ statically into the rustc_llvm.
|
|
|
|
# This is useful if you don't want to use the dynamic version of that
|
|
|
|
# library provided by LLVM.
|
|
|
|
#static-libstdcpp = false
|
2016-05-02 22:16:15 +00:00
|
|
|
|
2020-07-29 18:37:33 +00:00
|
|
|
# Whether to use Ninja to build LLVM. This runs much faster than make.
|
|
|
|
#ninja = true
|
2016-05-02 22:16:15 +00:00
|
|
|
|
2016-12-28 18:23:38 +00:00
|
|
|
# LLVM targets to build support for.
|
|
|
|
# Note: this is NOT related to Rust compilation targets. However, as Rust is
|
|
|
|
# dependent on LLVM for code generation, turning targets off here WILL lead to
|
|
|
|
# the resulting rustc being unable to compile for the disabled architectures.
|
2023-03-02 07:48:31 +00:00
|
|
|
#
|
|
|
|
# To add support for new targets, see https://rustc-dev-guide.rust-lang.org/building/new-target.html.
|
2022-07-07 07:46:10 +00:00
|
|
|
#targets = "AArch64;ARM;BPF;Hexagon;LoongArch;MSP430;Mips;NVPTX;PowerPC;RISCV;Sparc;SystemZ;WebAssembly;X86"
|
2016-12-28 18:23:38 +00:00
|
|
|
|
2017-06-16 22:43:43 +00:00
|
|
|
# LLVM experimental targets to build support for. These targets are specified in
|
|
|
|
# the same format as above, but since these targets are experimental, they are
|
|
|
|
# not built by default and the experimental Rust compilation targets that depend
|
2019-08-02 16:05:59 +00:00
|
|
|
# on them will not work unless the user opts in to building them.
|
2023-07-13 14:19:59 +00:00
|
|
|
#experimental-targets = "AVR;M68k;CSKY"
|
2017-06-16 22:43:43 +00:00
|
|
|
|
2017-03-05 15:11:11 +00:00
|
|
|
# Cap the number of parallel linker invocations when compiling LLVM.
|
|
|
|
# This can be useful when building LLVM with debug info, which significantly
|
|
|
|
# increases the size of binaries and consequently the memory required by
|
|
|
|
# each linker process.
|
2023-03-02 07:48:31 +00:00
|
|
|
# If set to 0, linker invocations are treated like any other job and
|
2017-03-05 15:11:11 +00:00
|
|
|
# controlled by rustbuild's -j parameter.
|
|
|
|
#link-jobs = 0
|
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Whether to build LLVM as a dynamically linked library (as opposed to statically linked).
|
|
|
|
# Under the hood, this passes `--shared` to llvm-config.
|
|
|
|
# NOTE: To avoid performing LTO multiple times, we suggest setting this to `true` when `thin-lto` is enabled.
|
|
|
|
#link-shared = llvm.thin-lto
|
2017-08-26 22:01:48 +00:00
|
|
|
|
2018-09-06 09:06:32 +00:00
|
|
|
# When building llvm, this configures what is being appended to the version.
|
2023-03-02 07:48:31 +00:00
|
|
|
# To use LLVM version as is, provide an empty string.
|
|
|
|
#version-suffix = if rust.channel == "dev" { "-rust-dev" } else { "-rust-$version-$channel" }
|
2018-09-06 09:06:32 +00:00
|
|
|
|
2018-04-24 15:34:14 +00:00
|
|
|
# On MSVC you can compile LLVM with clang-cl, but the test suite doesn't pass
|
2021-02-23 18:01:39 +00:00
|
|
|
# with clang-cl, so this is special in that it only compiles LLVM with clang-cl.
|
|
|
|
# Note that this takes a /path/to/clang-cl, not a boolean.
|
|
|
|
#clang-cl = cc
|
2018-04-24 15:34:14 +00:00
|
|
|
|
2018-11-14 00:25:51 +00:00
|
|
|
# Pass extra compiler and linker flags to the LLVM CMake build.
|
2021-02-23 18:01:39 +00:00
|
|
|
#cflags = ""
|
|
|
|
#cxxflags = ""
|
|
|
|
#ldflags = ""
|
2018-11-14 00:25:51 +00:00
|
|
|
|
2018-11-14 00:25:51 +00:00
|
|
|
# Use libc++ when building LLVM instead of libstdc++. This is the default on
|
|
|
|
# platforms already use libc++ as the default C++ library, but this option
|
|
|
|
# allows you to use libc++ even on platforms when it's not. You need to ensure
|
|
|
|
# that your host compiler ships with libc++.
|
2021-02-23 18:01:39 +00:00
|
|
|
#use-libcxx = false
|
2018-11-14 00:25:51 +00:00
|
|
|
|
2019-01-30 12:27:12 +00:00
|
|
|
# The value specified here will be passed as `-DLLVM_USE_LINKER` to CMake.
|
2021-02-23 18:01:39 +00:00
|
|
|
#use-linker = <none> (path)
|
2019-01-30 12:27:12 +00:00
|
|
|
|
2019-02-27 16:03:54 +00:00
|
|
|
# Whether or not to specify `-DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=YES`
|
|
|
|
#allow-old-toolchain = false
|
2019-01-30 12:27:12 +00:00
|
|
|
|
2020-10-30 10:19:56 +00:00
|
|
|
# Whether to include the Polly optimizer.
|
|
|
|
#polly = false
|
|
|
|
|
2021-07-20 00:38:39 +00:00
|
|
|
# Whether to build the clang compiler.
|
|
|
|
#clang = false
|
|
|
|
|
2023-03-10 16:47:09 +00:00
|
|
|
# Whether to enable llvm compilation warnings.
|
|
|
|
#enable-warnings = false
|
|
|
|
|
2022-02-08 01:56:53 +00:00
|
|
|
# Custom CMake defines to set when building LLVM.
|
|
|
|
#build-config = {}
|
|
|
|
|
2016-05-02 22:16:15 +00:00
|
|
|
# =============================================================================
|
|
|
|
# General build configuration options
|
|
|
|
# =============================================================================
|
|
|
|
[build]
|
2023-03-03 22:27:29 +00:00
|
|
|
|
2021-02-23 18:01:39 +00:00
|
|
|
# The default stage to use for the `check` subcommand
|
|
|
|
#check-stage = 0
|
|
|
|
|
2020-09-12 02:17:16 +00:00
|
|
|
# The default stage to use for the `doc` subcommand
|
|
|
|
#doc-stage = 0
|
|
|
|
|
|
|
|
# The default stage to use for the `build` subcommand
|
|
|
|
#build-stage = 1
|
|
|
|
|
|
|
|
# The default stage to use for the `test` subcommand
|
|
|
|
#test-stage = 1
|
|
|
|
|
|
|
|
# The default stage to use for the `dist` subcommand
|
|
|
|
#dist-stage = 2
|
|
|
|
|
|
|
|
# The default stage to use for the `install` subcommand
|
|
|
|
#install-stage = 2
|
|
|
|
|
|
|
|
# The default stage to use for the `bench` subcommand
|
|
|
|
#bench-stage = 2
|
2016-05-02 22:16:15 +00:00
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Build triple for the pre-compiled snapshot compiler. If `rustc` is set, this must match its host
|
|
|
|
# triple (see `rustc --version --verbose`; cross-compiling the rust build system itself is NOT
|
|
|
|
# supported). If `rustc` is unset, this must be a platform with pre-compiled host tools
|
|
|
|
# (https://doc.rust-lang.org/nightly/rustc/platform-support.html). The current platform must be
|
|
|
|
# able to run binaries of this build triple.
|
2020-06-22 22:29:55 +00:00
|
|
|
#
|
2023-03-02 07:48:31 +00:00
|
|
|
# If `rustc` is present in path, this defaults to the host it was compiled for.
|
|
|
|
# Otherwise, `x.py` will try to infer it from the output of `uname`.
|
|
|
|
# If `uname` is not found in PATH, we assume this is `x86_64-pc-windows-msvc`.
|
|
|
|
# This may be changed in the future.
|
2021-02-23 18:01:39 +00:00
|
|
|
#build = "x86_64-unknown-linux-gnu" (as an example)
|
2016-05-02 22:16:15 +00:00
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Which triples to produce a compiler toolchain for. Each of these triples will be bootstrapped from
|
|
|
|
# the build triple themselves. In other words, this is the list of triples for which to build a
|
|
|
|
# compiler that can RUN on that triple.
|
2020-06-22 22:29:55 +00:00
|
|
|
#
|
2023-03-02 07:48:31 +00:00
|
|
|
# Defaults to just the `build` triple.
|
|
|
|
#host = [build.build] (list of triples)
|
2016-05-02 22:16:15 +00:00
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Which triples to build libraries (core/alloc/std/test/proc_macro) for. Each of these triples will
|
|
|
|
# be bootstrapped from the build triple themselves. In other words, this is the list of triples for
|
|
|
|
# which to build a library that can CROSS-COMPILE to that triple.
|
2020-06-22 22:29:55 +00:00
|
|
|
#
|
2020-09-06 16:57:13 +00:00
|
|
|
# Defaults to `host`. If you set this explicitly, you likely want to add all
|
|
|
|
# host triples to this list as well in order for those host toolchains to be
|
|
|
|
# able to compile programs for their native target.
|
2023-03-02 07:48:31 +00:00
|
|
|
#target = build.host (list of triples)
|
2016-05-02 22:16:15 +00:00
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Use this directory to store build artifacts. Paths are relative to the current directory, not to
|
|
|
|
# the root of the repository.
|
2020-05-07 20:51:03 +00:00
|
|
|
#build-dir = "build"
|
|
|
|
|
2021-10-13 07:47:15 +00:00
|
|
|
# Instead of downloading the src/stage0.json version of Cargo specified, use
|
2016-05-02 22:16:15 +00:00
|
|
|
# this Cargo binary instead to build all Rust code
|
2023-03-02 07:48:31 +00:00
|
|
|
# If you set this, you likely want to set `rustc` as well.
|
2021-02-23 18:01:39 +00:00
|
|
|
#cargo = "/path/to/cargo"
|
2016-05-02 22:16:15 +00:00
|
|
|
|
2021-10-13 07:47:15 +00:00
|
|
|
# Instead of downloading the src/stage0.json version of the compiler
|
2016-05-02 22:16:15 +00:00
|
|
|
# specified, use this rustc binary instead as the stage0 snapshot compiler.
|
2023-03-02 07:48:31 +00:00
|
|
|
# If you set this, you likely want to set `cargo` as well.
|
2021-02-23 18:01:39 +00:00
|
|
|
#rustc = "/path/to/rustc"
|
2016-05-02 22:16:15 +00:00
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Instead of downloading the src/stage0.json version of rustfmt specified,
|
2019-12-27 05:32:12 +00:00
|
|
|
# use this rustfmt binary instead as the stage0 snapshot rustfmt.
|
2021-02-23 18:01:39 +00:00
|
|
|
#rustfmt = "/path/to/rustfmt"
|
2019-12-27 05:32:12 +00:00
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Whether to build documentation by default. If false, rustdoc and
|
2016-05-02 22:16:15 +00:00
|
|
|
# friends will still be compiled but they will not be used to generate any
|
|
|
|
# documentation.
|
2023-03-02 07:48:31 +00:00
|
|
|
#
|
|
|
|
# You can still build documentation when this is disabled by explicitly passing paths,
|
|
|
|
# e.g. `x doc library`.
|
2016-05-02 22:16:15 +00:00
|
|
|
#docs = true
|
|
|
|
|
2021-03-12 18:41:46 +00:00
|
|
|
# Flag to specify whether CSS, JavaScript, and HTML are minified when
|
|
|
|
# docs are generated. JSON is always minified, because it's enormous,
|
|
|
|
# and generated in already-minified form from the beginning.
|
|
|
|
#docs-minification = true
|
|
|
|
|
2023-01-24 16:00:45 +00:00
|
|
|
# Flag to specify whether private items should be included in the library docs.
|
|
|
|
#library-docs-private-items = false
|
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Indicate whether to build compiler documentation by default.
|
|
|
|
# You can still build documentation when this is disabled by explicitly passing a path: `x doc compiler`.
|
2016-05-02 22:16:15 +00:00
|
|
|
#compiler-docs = false
|
|
|
|
|
2019-08-16 16:39:45 +00:00
|
|
|
# Indicate whether git submodules are managed and updated automatically.
|
2016-10-07 16:43:26 +00:00
|
|
|
#submodules = true
|
|
|
|
|
2016-11-14 16:04:39 +00:00
|
|
|
# The path to (or name of) the GDB executable to use. This is only used for
|
|
|
|
# executing the debuginfo test suite.
|
2016-10-29 18:11:53 +00:00
|
|
|
#gdb = "gdb"
|
|
|
|
|
2016-11-14 16:04:39 +00:00
|
|
|
# The node.js executable to use. Note that this is only used for the emscripten
|
|
|
|
# target when running tests, otherwise this can be omitted.
|
|
|
|
#nodejs = "node"
|
|
|
|
|
2023-06-12 15:31:42 +00:00
|
|
|
# The npm executable to use. Note that this is used for rustdoc-gui tests,
|
|
|
|
# otherwise this can be omitted.
|
|
|
|
#
|
|
|
|
# Under Windows this should be `npm.cmd` or path to it (verified on nodejs v18.06), or
|
|
|
|
# error will be emitted.
|
|
|
|
#npm = "npm"
|
|
|
|
|
2016-11-14 16:04:39 +00:00
|
|
|
# Python interpreter to use for various tasks throughout the build, notably
|
|
|
|
# rustdoc tests, the lldb python interpreter, and some dist bits and pieces.
|
2020-06-22 22:29:55 +00:00
|
|
|
#
|
2023-03-02 07:48:31 +00:00
|
|
|
# Defaults to the Python interpreter used to execute x.py.
|
2020-06-22 22:29:55 +00:00
|
|
|
#python = "python"
|
2016-11-14 16:04:39 +00:00
|
|
|
|
2022-11-24 16:25:35 +00:00
|
|
|
# The path to the REUSE executable to use. Note that REUSE is not required in
|
2023-04-10 19:02:49 +00:00
|
|
|
# most cases, as our tooling relies on a cached (and shrunk) copy of the
|
2022-11-24 16:25:35 +00:00
|
|
|
# REUSE output present in the git repository and in our source tarballs.
|
2022-11-08 11:27:49 +00:00
|
|
|
#
|
2023-03-02 07:48:31 +00:00
|
|
|
# REUSE is only needed if your changes caused the overall licensing of the
|
2022-11-24 16:25:35 +00:00
|
|
|
# repository to change, and the cached copy has to be regenerated.
|
|
|
|
#
|
|
|
|
# Defaults to the "reuse" command in the system path.
|
2022-11-08 11:27:49 +00:00
|
|
|
#reuse = "reuse"
|
|
|
|
|
2017-02-10 20:59:40 +00:00
|
|
|
# Force Cargo to check that Cargo.lock describes the precise dependency
|
|
|
|
# set that all the Cargo.toml files create, instead of updating it.
|
|
|
|
#locked-deps = false
|
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Indicate whether the vendored sources are used for Rust dependencies or not.
|
|
|
|
#
|
|
|
|
# Vendoring requires additional setup. We recommend using the pre-generated source tarballs if you
|
|
|
|
# want to use vendoring. See
|
|
|
|
# https://forge.rust-lang.org/infra/other-installation-methods.html#source-code.
|
2016-11-01 20:46:38 +00:00
|
|
|
#vendor = false
|
|
|
|
|
2020-01-11 13:04:06 +00:00
|
|
|
# Typically the build system will build the Rust compiler twice. The second
|
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 23:20:33 +00:00
|
|
|
# compiler, however, will simply use its own libraries to link against. If you
|
|
|
|
# would rather to perform a full bootstrap, compiling the compiler three times,
|
2023-03-02 07:48:31 +00:00
|
|
|
# then you can set this option to true.
|
|
|
|
#
|
|
|
|
# This is only useful for verifying that rustc generates reproducible builds.
|
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 23:20:33 +00:00
|
|
|
#full-bootstrap = false
|
|
|
|
|
2020-01-11 13:04:06 +00:00
|
|
|
# Enable a build of the extended Rust tool set which is not only the compiler
|
2017-09-06 22:22:32 +00:00
|
|
|
# but also tools such as Cargo. This will also produce "combined installers"
|
2023-09-10 20:53:00 +00:00
|
|
|
# which are used to install Rust and Cargo together.
|
|
|
|
# The `tools` (check `config.example.toml` to see its default value) option specifies
|
|
|
|
# which tools should be built if `extended = true`.
|
|
|
|
#
|
|
|
|
# This is disabled by default.
|
2017-01-21 01:03:06 +00:00
|
|
|
#extended = false
|
|
|
|
|
2023-01-14 21:49:00 +00:00
|
|
|
# Set of tools to be included in the installation.
|
|
|
|
#
|
|
|
|
# If `extended = false`, the only one of these built by default is rustdoc.
|
|
|
|
#
|
|
|
|
# If `extended = true`, they're all included, with the exception of
|
|
|
|
# rust-demangler which additionally requires `profiler = true` to be set.
|
|
|
|
#
|
|
|
|
# If any enabled tool fails to build, the installation fails.
|
|
|
|
#tools = [
|
|
|
|
# "cargo",
|
|
|
|
# "clippy",
|
|
|
|
# "rustdoc",
|
|
|
|
# "rustfmt",
|
|
|
|
# "rust-analyzer",
|
|
|
|
# "analysis",
|
|
|
|
# "src",
|
|
|
|
# "rust-demangler", # if profiler = true
|
|
|
|
#]
|
2018-02-05 17:10:05 +00:00
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Verbosity level: 0 == not verbose, 1 == verbose, 2 == very verbose, 3 == print environment variables on each rustc invocation
|
2017-02-06 19:47:04 +00:00
|
|
|
#verbose = 0
|
|
|
|
|
2017-02-03 23:58:47 +00:00
|
|
|
# Build the sanitizer runtimes
|
|
|
|
#sanitizers = false
|
|
|
|
|
2020-06-17 01:48:46 +00:00
|
|
|
# Build the profiler runtime (required when compiling with options that depend
|
2021-10-21 14:04:22 +00:00
|
|
|
# on this runtime, such as `-C profile-generate` or `-C instrument-coverage`).
|
2017-02-13 09:57:50 +00:00
|
|
|
#profiler = false
|
|
|
|
|
2018-10-08 17:39:09 +00:00
|
|
|
# Indicates whether the native libraries linked into Cargo will be statically
|
|
|
|
# linked or not.
|
|
|
|
#cargo-native-static = false
|
2017-02-15 23:57:06 +00:00
|
|
|
|
2017-05-18 16:00:31 +00:00
|
|
|
# Run the build with low priority, by setting the process group's "nice" value
|
|
|
|
# to +10 on Unix platforms, and by using a "low priority" job object on Windows.
|
|
|
|
#low-priority = false
|
2017-03-23 21:57:29 +00:00
|
|
|
|
2017-08-26 22:01:48 +00:00
|
|
|
# Arguments passed to the `./configure` script, used during distcheck. You
|
|
|
|
# probably won't fill this in but rather it's filled in by the `./configure`
|
2023-03-02 07:48:31 +00:00
|
|
|
# script. Useful for debugging.
|
2017-08-26 22:01:48 +00:00
|
|
|
#configure-args = []
|
|
|
|
|
2017-09-06 22:22:32 +00:00
|
|
|
# Indicates that a local rebuild is occurring instead of a full bootstrap,
|
2017-08-26 22:01:48 +00:00
|
|
|
# essentially skipping stage0 as the local compiler is recompiling itself again.
|
2023-03-02 07:48:31 +00:00
|
|
|
# Useful for modifying only the stage2 compiler without having to pass `--keep-stage 0` each time.
|
2017-08-26 22:01:48 +00:00
|
|
|
#local-rebuild = false
|
|
|
|
|
2018-03-16 19:10:47 +00:00
|
|
|
# Print out how long each rustbuild step took (mostly intended for CI and
|
|
|
|
# tracking over time)
|
|
|
|
#print-step-timings = false
|
|
|
|
|
2021-02-19 18:25:26 +00:00
|
|
|
# Print out resource usage data for each rustbuild step, as defined by the Unix
|
|
|
|
# struct rusage. (Note that this setting is completely unstable: the data it
|
|
|
|
# captures, what platforms it supports, the format of its associated output, and
|
|
|
|
# this setting's very existence, are all subject to change.)
|
|
|
|
#print-step-rusage = false
|
|
|
|
|
2021-10-01 12:41:18 +00:00
|
|
|
# Always patch binaries for usage with Nix toolchains. If `true` then binaries
|
|
|
|
# will be patched unconditionally. If `false` or unset, binaries will be patched
|
|
|
|
# only if the current distribution is NixOS. This option is useful when using
|
|
|
|
# a Nix toolchain on non-NixOS distributions.
|
|
|
|
#patch-binaries-for-nix = false
|
|
|
|
|
2022-02-06 22:03:55 +00:00
|
|
|
# Collect information and statistics about the current build and writes it to
|
|
|
|
# disk. Enabling this or not has no impact on the resulting build output. The
|
|
|
|
# schema of the file generated by the build metrics feature is unstable, and
|
|
|
|
# this is not intended to be used during local development.
|
|
|
|
#metrics = false
|
|
|
|
|
2022-10-13 00:02:31 +00:00
|
|
|
# Specify the location of the Android NDK. Used when targeting Android.
|
|
|
|
#android-ndk = "/path/to/android-ndk-r25b"
|
|
|
|
|
2016-12-19 22:49:57 +00:00
|
|
|
# =============================================================================
|
|
|
|
# General install configuration options
|
|
|
|
# =============================================================================
|
|
|
|
[install]
|
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Where to install the generated toolchain. Must be an absolute path.
|
2016-12-28 17:18:54 +00:00
|
|
|
#prefix = "/usr/local"
|
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Where to install system configuration files.
|
2017-04-28 09:03:58 +00:00
|
|
|
# If this is a relative path, it will get installed in `prefix` above
|
|
|
|
#sysconfdir = "/etc"
|
|
|
|
|
2017-04-28 09:01:15 +00:00
|
|
|
# Where to install documentation in `prefix` above
|
|
|
|
#docdir = "share/doc/rust"
|
|
|
|
|
|
|
|
# Where to install binaries in `prefix` above
|
|
|
|
#bindir = "bin"
|
|
|
|
|
2016-12-28 17:18:54 +00:00
|
|
|
# Where to install libraries in `prefix` above
|
|
|
|
#libdir = "lib"
|
|
|
|
|
|
|
|
# Where to install man pages in `prefix` above
|
|
|
|
#mandir = "share/man"
|
|
|
|
|
2021-02-23 18:01:39 +00:00
|
|
|
# Where to install data in `prefix` above
|
2017-10-26 23:30:17 +00:00
|
|
|
#datadir = "share"
|
|
|
|
|
2016-05-02 22:16:15 +00:00
|
|
|
# =============================================================================
|
|
|
|
# Options for compiling Rust code itself
|
|
|
|
# =============================================================================
|
|
|
|
[rust]
|
|
|
|
|
2023-07-03 01:16:44 +00:00
|
|
|
# Whether or not to optimize when compiling the compiler and standard library,
|
|
|
|
# and what level of optimization to use.
|
2019-10-24 15:41:48 +00:00
|
|
|
# WARNING: Building with optimize = false is NOT SUPPORTED. Due to bootstrapping,
|
|
|
|
# building without optimizations takes much longer than optimizing. Further, some platforms
|
|
|
|
# fail to build without this optimization (c.f. #65352).
|
2023-07-03 01:16:44 +00:00
|
|
|
# The valid options are:
|
|
|
|
# true - Enable optimizations.
|
|
|
|
# false - Disable optimizations.
|
|
|
|
# 0 - Disable optimizations.
|
|
|
|
# 1 - Basic optimizations.
|
|
|
|
# 2 - Some optimizations.
|
|
|
|
# 3 - All optimizations.
|
|
|
|
# "s" - Optimize for binary size.
|
|
|
|
# "z" - Optimize for binary size, but also turn off loop vectorization.
|
2016-05-02 22:16:15 +00:00
|
|
|
#optimize = true
|
|
|
|
|
2018-10-08 13:43:53 +00:00
|
|
|
# Indicates that the build should be configured for debugging Rust. A
|
|
|
|
# `debug`-enabled compiler and standard library will be somewhat
|
|
|
|
# slower (due to e.g. checking of debug assertions) but should remain
|
|
|
|
# usable.
|
|
|
|
#
|
|
|
|
# Note: If this value is set to `true`, it will affect a number of
|
|
|
|
# configuration options below as well, if they have been left
|
|
|
|
# unconfigured in this file.
|
|
|
|
#
|
|
|
|
# Note: changes to the `debug` setting do *not* affect `optimize`
|
|
|
|
# above. In theory, a "maximally debuggable" environment would
|
|
|
|
# set `optimize` to `false` above to assist the introspection
|
|
|
|
# facilities of debuggers like lldb and gdb. To recreate such an
|
|
|
|
# environment, explicitly set `optimize` to `false` and `debug`
|
|
|
|
# to `true`. In practice, everyone leaves `optimize` set to
|
|
|
|
# `true`, because an unoptimized rustc with debugging
|
|
|
|
# enabled becomes *unusably slow* (e.g. rust-lang/rust#24840
|
|
|
|
# reported a 25x slowdown) and bootstrapping the supposed
|
|
|
|
# "maximally debuggable" environment (notably libstd) takes
|
|
|
|
# hours to build.
|
|
|
|
#
|
|
|
|
#debug = false
|
|
|
|
|
2021-01-22 05:31:17 +00:00
|
|
|
# Whether to download the stage 1 and 2 compilers from CI.
|
2023-03-02 07:48:31 +00:00
|
|
|
# This is mostly useful for tools; if you have changes to `compiler/` or `library/` they will be ignored.
|
2021-01-22 05:31:17 +00:00
|
|
|
#
|
2023-03-02 07:48:31 +00:00
|
|
|
# Set this to "if-unchanged" to only download if the compiler and standard library have not been modified.
|
|
|
|
# Set this to `true` to download unconditionally (useful if e.g. you are only changing doc-comments).
|
2021-01-22 05:31:17 +00:00
|
|
|
#download-rustc = false
|
|
|
|
|
2016-05-02 22:16:15 +00:00
|
|
|
# Number of codegen units to use for each compiler invocation. A value of 0
|
|
|
|
# means "the number of cores on this machine", and 1+ is passed through to the
|
|
|
|
# compiler.
|
2020-08-31 02:35:12 +00:00
|
|
|
#
|
2020-09-01 17:37:40 +00:00
|
|
|
# Uses the rustc defaults: https://doc.rust-lang.org/rustc/codegen-options/index.html#codegen-units
|
2020-08-31 04:37:50 +00:00
|
|
|
#codegen-units = if incremental { 256 } else { 16 }
|
2016-05-02 22:16:15 +00:00
|
|
|
|
2018-10-22 14:39:36 +00:00
|
|
|
# Sets the number of codegen units to build the standard library with,
|
|
|
|
# regardless of what the codegen-unit setting for the rest of the compiler is.
|
2021-02-23 18:01:39 +00:00
|
|
|
# NOTE: building with anything other than 1 is known to occasionally have bugs.
|
|
|
|
#codegen-units-std = codegen-units
|
2018-10-22 14:39:36 +00:00
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Whether or not debug assertions are enabled for the compiler and standard library.
|
|
|
|
# These can help find bugs at the cost of a small runtime slowdown.
|
2020-06-22 22:29:55 +00:00
|
|
|
#
|
|
|
|
# Defaults to rust.debug value
|
2020-10-09 20:36:33 +00:00
|
|
|
#debug-assertions = rust.debug (boolean)
|
2016-05-02 22:16:15 +00:00
|
|
|
|
2020-05-12 17:00:10 +00:00
|
|
|
# Whether or not debug assertions are enabled for the standard library.
|
|
|
|
# Overrides the `debug-assertions` option, if defined.
|
2020-06-22 22:29:55 +00:00
|
|
|
#
|
2020-06-24 02:47:20 +00:00
|
|
|
# Defaults to rust.debug-assertions value
|
2020-10-09 20:36:33 +00:00
|
|
|
#debug-assertions-std = rust.debug-assertions (boolean)
|
2020-05-12 17:00:10 +00:00
|
|
|
|
2020-09-10 21:58:45 +00:00
|
|
|
# Whether or not to leave debug! and trace! calls in the rust binary.
|
2020-09-23 23:05:11 +00:00
|
|
|
#
|
2020-09-10 21:58:45 +00:00
|
|
|
# Defaults to rust.debug-assertions value
|
2020-10-08 13:16:27 +00:00
|
|
|
#
|
2023-03-02 07:48:31 +00:00
|
|
|
# If you see a message from `tracing` saying "some trace filter directives would enable traces that
|
|
|
|
# are disabled statically" because `max_level_info` is enabled, set this value to `true`.
|
2020-10-09 20:36:33 +00:00
|
|
|
#debug-logging = rust.debug-assertions (boolean)
|
2020-05-12 17:00:10 +00:00
|
|
|
|
2021-10-11 17:54:27 +00:00
|
|
|
# Whether or not overflow checks are enabled for the compiler and standard
|
|
|
|
# library.
|
|
|
|
#
|
|
|
|
# Defaults to rust.debug value
|
|
|
|
#overflow-checks = rust.debug (boolean)
|
|
|
|
|
|
|
|
# Whether or not overflow checks are enabled for the standard library.
|
|
|
|
# Overrides the `overflow-checks` option, if defined.
|
|
|
|
#
|
|
|
|
# Defaults to rust.overflow-checks value
|
|
|
|
#overflow-checks-std = rust.overflow-checks (boolean)
|
|
|
|
|
2019-05-23 23:11:33 +00:00
|
|
|
# Debuginfo level for most of Rust code, corresponds to the `-C debuginfo=N` option of `rustc`.
|
2019-05-05 19:15:42 +00:00
|
|
|
# `0` - no debug info
|
2020-07-05 00:00:00 +00:00
|
|
|
# `1` - line tables only - sufficient to generate backtraces that include line
|
|
|
|
# information and inlined functions, set breakpoints at source code
|
|
|
|
# locations, and step through execution in a debugger.
|
2019-05-05 19:15:42 +00:00
|
|
|
# `2` - full debug info with variable and type information
|
2020-03-06 11:13:55 +00:00
|
|
|
# Can be overridden for specific subsets of Rust code (rustc, std or tools).
|
2019-05-23 23:11:33 +00:00
|
|
|
# Debuginfo for tests run with compiletest is not controlled by this option
|
|
|
|
# and needs to be enabled separately with `debuginfo-level-tests`.
|
2020-06-22 22:29:55 +00:00
|
|
|
#
|
2020-07-02 12:59:50 +00:00
|
|
|
# Note that debuginfo-level = 2 generates several gigabytes of debuginfo
|
|
|
|
# and will slow down the linking process significantly.
|
2023-03-02 07:48:31 +00:00
|
|
|
#debuginfo-level = if rust.debug { 1 } else { 0 }
|
2016-05-02 22:16:15 +00:00
|
|
|
|
2019-05-05 19:15:42 +00:00
|
|
|
# Debuginfo level for the compiler.
|
2023-03-02 07:48:31 +00:00
|
|
|
#debuginfo-level-rustc = rust.debuginfo-level
|
2016-10-19 16:48:46 +00:00
|
|
|
|
2019-05-05 19:15:42 +00:00
|
|
|
# Debuginfo level for the standard library.
|
2023-03-02 07:48:31 +00:00
|
|
|
#debuginfo-level-std = rust.debuginfo-level
|
2017-01-11 04:01:54 +00:00
|
|
|
|
2019-05-05 19:15:42 +00:00
|
|
|
# Debuginfo level for the tools.
|
2023-03-02 07:48:31 +00:00
|
|
|
#debuginfo-level-tools = rust.debuginfo-level
|
2019-05-05 19:15:42 +00:00
|
|
|
|
|
|
|
# Debuginfo level for the test suites run with compiletest.
|
2019-05-24 10:01:23 +00:00
|
|
|
# FIXME(#61117): Some tests fail when this option is enabled.
|
2019-05-23 23:11:33 +00:00
|
|
|
#debuginfo-level-tests = 0
|
2018-04-13 23:52:54 +00:00
|
|
|
|
2022-02-14 03:39:32 +00:00
|
|
|
# Should rustc be build with split debuginfo? Default is platform dependent.
|
|
|
|
# Valid values are the same as those accepted by `-C split-debuginfo`
|
|
|
|
# (`off`/`unpacked`/`packed`).
|
|
|
|
#
|
2022-04-03 05:35:49 +00:00
|
|
|
# On Linux, split debuginfo is disabled by default.
|
2022-02-14 03:39:32 +00:00
|
|
|
#
|
|
|
|
# On Apple platforms, unpacked split debuginfo is used by default. Unpacked
|
|
|
|
# debuginfo does not run `dsymutil`, which packages debuginfo from disparate
|
|
|
|
# object files into a single `.dSYM` file. `dsymutil` adds time to builds for
|
|
|
|
# no clear benefit, and also makes it more difficult for debuggers to find
|
|
|
|
# debug info. The compiler currently defaults to running `dsymutil` to preserve
|
|
|
|
# its historical default, but when compiling the compiler itself, we skip it by
|
|
|
|
# default since we know it's safe to do so in that case.
|
|
|
|
#
|
|
|
|
# On Windows platforms, packed debuginfo is the only supported option,
|
|
|
|
# producing a `.pdb` file.
|
2022-04-03 05:35:49 +00:00
|
|
|
#split-debuginfo = if linux { off } else if windows { packed } else if apple { unpacked }
|
2020-12-20 02:49:18 +00:00
|
|
|
|
2016-07-26 20:21:25 +00:00
|
|
|
# Whether or not `panic!`s generate backtraces (RUST_BACKTRACE)
|
|
|
|
#backtrace = true
|
|
|
|
|
2018-06-02 22:13:27 +00:00
|
|
|
# Whether to always use incremental compilation when building rustc
|
|
|
|
#incremental = false
|
|
|
|
|
2019-01-28 18:24:07 +00:00
|
|
|
# Build a multi-threaded rustc
|
2020-09-07 11:58:48 +00:00
|
|
|
# FIXME(#75760): Some UI tests fail when this option is enabled.
|
2023-03-02 07:48:31 +00:00
|
|
|
# NOTE: This option is NOT SUPPORTED. See #48685.
|
2019-01-28 14:51:47 +00:00
|
|
|
#parallel-compiler = false
|
2018-03-17 21:17:33 +00:00
|
|
|
|
2021-11-29 21:56:45 +00:00
|
|
|
# The default linker that will be hard-coded into the generated
|
|
|
|
# compiler for targets that don't specify a default linker explicitly
|
|
|
|
# in their target specifications. Note that this is not the linker
|
|
|
|
# used to link said compiler. It can also be set per-target (via the
|
|
|
|
# `[target.<triple>]` block), which may be useful in a cross-compilation
|
|
|
|
# setting.
|
2021-02-23 18:01:39 +00:00
|
|
|
#
|
|
|
|
# See https://doc.rust-lang.org/rustc/codegen-options/index.html#linker for more information.
|
|
|
|
#default-linker = <none> (path)
|
2016-05-02 22:16:15 +00:00
|
|
|
|
|
|
|
# The "channel" for the Rust build to produce. The stable/beta channels only
|
|
|
|
# allow using stable features, whereas the nightly and dev channels allow using
|
|
|
|
# nightly features
|
|
|
|
#channel = "dev"
|
|
|
|
|
2020-11-16 22:08:21 +00:00
|
|
|
# A descriptive string to be appended to `rustc --version` output, which is
|
|
|
|
# also used in places like debuginfo `DW_AT_producer`. This may be useful for
|
|
|
|
# supplementary build information, like distro-specific package versions.
|
2022-08-24 16:36:08 +00:00
|
|
|
#
|
|
|
|
# The Rust compiler will differentiate between versions of itself, including
|
|
|
|
# based on this string, which means that if you wish to be compatible with
|
|
|
|
# upstream Rust you need to set this to "". However, note that if you are not
|
|
|
|
# actually compatible -- for example if you've backported patches that change
|
|
|
|
# behavior -- this may lead to miscompilations or other bugs.
|
2023-03-02 07:48:31 +00:00
|
|
|
#description = ""
|
2020-11-16 22:08:21 +00:00
|
|
|
|
2021-02-23 18:01:39 +00:00
|
|
|
# The root location of the musl installation directory. The library directory
|
|
|
|
# will also need to contain libunwind.a for an unwinding implementation. Note
|
|
|
|
# that this option only makes sense for musl targets that produce statically
|
|
|
|
# linked binaries.
|
|
|
|
#
|
|
|
|
# Defaults to /usr on musl hosts. Has no default otherwise.
|
|
|
|
#musl-root = <platform specific> (path)
|
2019-10-24 15:43:06 +00:00
|
|
|
|
2016-05-02 22:16:15 +00:00
|
|
|
# By default the `rustc` executable is built with `-Wl,-rpath` flags on Unix
|
|
|
|
# platforms to ensure that the compiler is usable by default from the build
|
|
|
|
# directory (as it links to a number of dynamic libraries). This may not be
|
|
|
|
# desired in distributions, for example.
|
|
|
|
#rpath = true
|
|
|
|
|
2020-08-31 04:37:50 +00:00
|
|
|
# Prints each test name as it is executed, to help debug issues in the test harness itself.
|
2018-06-07 12:40:36 +00:00
|
|
|
#verbose-tests = false
|
2017-08-26 22:01:48 +00:00
|
|
|
|
2019-05-24 10:01:23 +00:00
|
|
|
# Flag indicating whether tests are compiled with optimizations (the -O flag).
|
2016-05-13 22:26:41 +00:00
|
|
|
#optimize-tests = true
|
|
|
|
|
2016-09-03 01:29:12 +00:00
|
|
|
# Flag indicating whether codegen tests will be run or not. If you get an error
|
|
|
|
# saying that the FileCheck executable is missing, you may want to disable this.
|
2018-09-25 15:13:02 +00:00
|
|
|
# Also see the target's llvm-filecheck option.
|
2016-09-03 01:29:12 +00:00
|
|
|
#codegen-tests = true
|
|
|
|
|
2017-08-03 16:53:56 +00:00
|
|
|
# Flag indicating whether git info will be retrieved from .git automatically.
|
2017-08-16 01:26:29 +00:00
|
|
|
# Having the git information can cause a lot of rebuilds during development.
|
2023-03-02 07:48:31 +00:00
|
|
|
#
|
|
|
|
# FIXME(#76720): this can causes bugs if different compilers reuse the same metadata cache.
|
2023-04-07 17:45:25 +00:00
|
|
|
#omit-git-hash = if rust.channel == "dev" { true } else { false }
|
2017-08-03 16:53:56 +00:00
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Whether to create a source tarball by default when running `x dist`.
|
|
|
|
#
|
|
|
|
# You can still build a source tarball when this is disabled by explicitly passing `x dist rustc-src`.
|
2021-02-23 18:01:39 +00:00
|
|
|
#dist-src = true
|
2017-08-26 22:01:48 +00:00
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# After building or testing an optional component (e.g. the nomicon or reference), append the
|
2017-11-30 10:18:47 +00:00
|
|
|
# result (broken, compiling, testing) into this JSON file.
|
2021-02-23 18:01:39 +00:00
|
|
|
#save-toolstates = <none> (path)
|
2017-11-30 10:18:47 +00:00
|
|
|
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 16:22:34 +00:00
|
|
|
# This is an array of the codegen backends that will be compiled for the rustc
|
|
|
|
# that's being compiled. The default is to only build the LLVM codegen backend,
|
2022-02-27 09:59:10 +00:00
|
|
|
# and currently the only standard options supported are `"llvm"`, `"cranelift"`
|
|
|
|
# and `"gcc"`. The first backend in this list will be used as default by rustc
|
|
|
|
# when no explicit backend is specified.
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 16:22:34 +00:00
|
|
|
#codegen-backends = ["llvm"]
|
|
|
|
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-27 01:30:12 +00:00
|
|
|
# Indicates whether LLD will be compiled and made available in the sysroot for
|
|
|
|
# rustc to execute.
|
|
|
|
#lld = false
|
|
|
|
|
2020-01-28 18:21:22 +00:00
|
|
|
# Indicates whether LLD will be used to link Rust crates during bootstrap on
|
|
|
|
# supported platforms. The LLD from the bootstrap distribution will be used
|
|
|
|
# and not the LLD compiled during the bootstrap.
|
2020-02-09 13:26:13 +00:00
|
|
|
#
|
2020-09-08 19:08:25 +00:00
|
|
|
# LLD will not be used if we're cross linking.
|
2020-02-09 13:35:50 +00:00
|
|
|
#
|
2020-08-03 13:39:09 +00:00
|
|
|
# Explicitly setting the linker for a target will override this option when targeting MSVC.
|
2020-01-28 18:21:22 +00:00
|
|
|
#use-lld = false
|
|
|
|
|
2018-04-30 08:15:48 +00:00
|
|
|
# Indicates whether some LLVM tools, like llvm-objdump, will be made available in the
|
|
|
|
# sysroot.
|
|
|
|
#llvm-tools = false
|
|
|
|
|
2018-04-01 15:35:53 +00:00
|
|
|
# Whether to deny warnings in crates
|
|
|
|
#deny-warnings = true
|
|
|
|
|
2018-04-08 11:44:29 +00:00
|
|
|
# Print backtrace on internal compiler errors during bootstrap
|
|
|
|
#backtrace-on-ice = false
|
|
|
|
|
2018-06-12 19:21:29 +00:00
|
|
|
# Whether to verify generated LLVM IR
|
|
|
|
#verify-llvm-ir = false
|
|
|
|
|
2019-12-20 13:38:28 +00:00
|
|
|
# Compile the compiler with a non-default ThinLTO import limit. This import
|
|
|
|
# limit controls the maximum size of functions imported by ThinLTO. Decreasing
|
|
|
|
# will make code compile faster at the expense of lower runtime performance.
|
2021-02-23 18:01:39 +00:00
|
|
|
#thin-lto-import-instr-limit = if incremental { 10 } else { LLVM default (currently 100) }
|
2019-12-20 13:38:28 +00:00
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Map debuginfo paths to `/rust/$sha/...`.
|
|
|
|
# Useful for reproducible builds. Generally only set for releases
|
2018-08-30 17:25:07 +00:00
|
|
|
#remap-debuginfo = false
|
|
|
|
|
2023-03-02 07:48:31 +00:00
|
|
|
# Link the compiler and LLVM against `jemalloc` instead of the default libc allocator.
|
|
|
|
# This option is only tested on Linux and OSX.
|
2018-10-21 02:15:06 +00:00
|
|
|
#jemalloc = false
|
|
|
|
|
2018-11-30 22:31:04 +00:00
|
|
|
# Run tests in various test suites with the "nll compare mode" in addition to
|
|
|
|
# running the tests in normal mode. Largely only used on CI and during local
|
|
|
|
# development of NLL
|
|
|
|
#test-compare-mode = false
|
|
|
|
|
2022-02-02 22:48:09 +00:00
|
|
|
# Global default for llvm-libunwind for all targets. See the target-specific
|
|
|
|
# documentation for llvm-libunwind below. Note that the target-specific
|
|
|
|
# option will override this if set.
|
2020-10-08 13:05:31 +00:00
|
|
|
#llvm-libunwind = 'no'
|
2019-03-11 02:27:59 +00:00
|
|
|
|
2020-01-28 14:29:44 +00:00
|
|
|
# Enable Windows Control Flow Guard checks in the standard library.
|
|
|
|
# This only applies from stage 1 onwards, and only for Windows targets.
|
|
|
|
#control-flow-guard = false
|
|
|
|
|
2020-08-12 22:42:42 +00:00
|
|
|
# Enable symbol-mangling-version v0. This can be helpful when profiling rustc,
|
|
|
|
# as generics will be preserved in symbols (rather than erased into opaque T).
|
2021-10-19 12:58:21 +00:00
|
|
|
# When no setting is given, the new scheme will be used when compiling the
|
|
|
|
# compiler and its tools and the legacy scheme will be used when compiling the
|
|
|
|
# standard library.
|
|
|
|
# If an explicit setting is given, it will be used for all parts of the codebase.
|
|
|
|
#new-symbol-mangling = true|false (see comment)
|
2020-08-12 22:42:42 +00:00
|
|
|
|
2022-09-29 14:31:03 +00:00
|
|
|
# Select LTO mode that will be used for compiling rustc. By default, thin local LTO
|
|
|
|
# (LTO within a single crate) is used (like for any Rust crate). You can also select
|
2023-01-23 21:21:35 +00:00
|
|
|
# "thin" or "fat" to apply Thin/Fat LTO to the `rustc_driver` dylib, or "off" to disable
|
|
|
|
# LTO entirely.
|
2022-09-29 14:31:03 +00:00
|
|
|
#lto = "thin-local"
|
2022-09-29 14:28:57 +00:00
|
|
|
|
2022-12-15 06:49:11 +00:00
|
|
|
# Build compiler with the optimization enabled and -Zvalidate-mir, currently only for `std`
|
|
|
|
#validate-mir-opts = 3
|
|
|
|
|
2016-05-02 22:16:15 +00:00
|
|
|
# =============================================================================
|
|
|
|
# Options for specific targets
|
|
|
|
#
|
|
|
|
# Each of the following options is scoped to the specific target triple in
|
|
|
|
# question and is used for determining how to compile each target.
|
|
|
|
# =============================================================================
|
|
|
|
[target.x86_64-unknown-linux-gnu]
|
|
|
|
|
2021-02-23 18:01:39 +00:00
|
|
|
# C compiler to be used to compile C code. Note that the
|
2016-05-02 22:16:15 +00:00
|
|
|
# default value is platform specific, and if not specified it may also depend on
|
|
|
|
# what platform is crossing to what platform.
|
2021-02-23 18:01:39 +00:00
|
|
|
# See `src/bootstrap/cc_detect.rs` for details.
|
|
|
|
#cc = "cc" (path)
|
2016-05-02 22:16:15 +00:00
|
|
|
|
2021-02-23 18:01:39 +00:00
|
|
|
# C++ compiler to be used to compile C++ code (e.g. LLVM and our LLVM shims).
|
2016-05-02 22:16:15 +00:00
|
|
|
# This is only used for host targets.
|
2021-02-23 18:01:39 +00:00
|
|
|
# See `src/bootstrap/cc_detect.rs` for details.
|
|
|
|
#cxx = "c++" (path)
|
2016-05-02 22:16:15 +00:00
|
|
|
|
2017-10-10 20:06:22 +00:00
|
|
|
# Archiver to be used to assemble static libraries compiled from C/C++ code.
|
|
|
|
# Note: an absolute path should be used, otherwise LLVM build will break.
|
2021-02-23 18:01:39 +00:00
|
|
|
#ar = "ar" (path)
|
2017-10-10 20:06:22 +00:00
|
|
|
|
2018-05-30 14:36:18 +00:00
|
|
|
# Ranlib to be used to assemble static libraries compiled from C/C++ code.
|
|
|
|
# Note: an absolute path should be used, otherwise LLVM build will break.
|
2021-02-23 18:01:39 +00:00
|
|
|
#ranlib = "ranlib" (path)
|
2018-05-30 14:36:18 +00:00
|
|
|
|
2021-02-23 18:01:39 +00:00
|
|
|
# Linker to be used to bootstrap Rust code. Note that the
|
2017-10-10 20:06:22 +00:00
|
|
|
# default value is platform specific, and if not specified it may also depend on
|
|
|
|
# what platform is crossing to what platform.
|
2020-08-03 13:39:09 +00:00
|
|
|
# Setting this will override the `use-lld` option for Rust code when targeting MSVC.
|
2021-02-23 18:01:39 +00:00
|
|
|
#linker = "cc" (path)
|
2017-10-10 20:06:22 +00:00
|
|
|
|
2016-05-02 22:16:15 +00:00
|
|
|
# Path to the `llvm-config` binary of the installation of a custom LLVM to link
|
2018-02-06 11:59:06 +00:00
|
|
|
# against. Note that if this is specified we don't compile LLVM at all for this
|
2016-05-02 22:16:15 +00:00
|
|
|
# target.
|
2021-02-23 18:01:39 +00:00
|
|
|
#llvm-config = <none> (path)
|
2016-05-02 22:16:15 +00:00
|
|
|
|
2022-08-27 02:24:41 +00:00
|
|
|
# Override detection of whether this is a Rust-patched LLVM. This would be used
|
|
|
|
# in conjunction with either an llvm-config or build.submodules = false.
|
|
|
|
#llvm-has-rust-patches = if llvm-config { false } else { true }
|
|
|
|
|
2018-09-25 15:13:02 +00:00
|
|
|
# Normally the build system can find LLVM's FileCheck utility, but if
|
|
|
|
# not, you can specify an explicit file name for it.
|
2021-02-23 18:01:39 +00:00
|
|
|
#llvm-filecheck = "/path/to/llvm-version/bin/FileCheck"
|
2018-09-25 15:13:02 +00:00
|
|
|
|
2022-02-02 22:48:09 +00:00
|
|
|
# Use LLVM libunwind as the implementation for Rust's unwinder.
|
|
|
|
# Accepted values are 'in-tree' (formerly true), 'system' or 'no' (formerly false).
|
|
|
|
# This option only applies for Linux and Fuchsia targets.
|
|
|
|
# On Linux target, if crt-static is not enabled, 'no' means dynamic link to
|
|
|
|
# `libgcc_s.so`, 'in-tree' means static link to the in-tree build of llvm libunwind
|
|
|
|
# and 'system' means dynamic link to `libunwind.so`. If crt-static is enabled,
|
|
|
|
# the behavior is depend on the libc. On musl target, 'no' and 'in-tree' both
|
|
|
|
# means static link to the in-tree build of llvm libunwind, and 'system' means
|
|
|
|
# static link to `libunwind.a` provided by system. Due to the limitation of glibc,
|
|
|
|
# it must link to `libgcc_eh.a` to get a working output, and this option have no effect.
|
|
|
|
#llvm-libunwind = 'no' if Linux, 'in-tree' if Fuchsia
|
|
|
|
|
2020-10-25 12:13:14 +00:00
|
|
|
# Build the sanitizer runtimes for this target.
|
|
|
|
# This option will override the same option under [build] section.
|
2021-02-23 18:01:39 +00:00
|
|
|
#sanitizers = build.sanitizers (bool)
|
2020-10-25 12:13:14 +00:00
|
|
|
|
2023-07-26 16:34:39 +00:00
|
|
|
# When true, build the profiler runtime for this target (required when compiling
|
2023-07-25 20:11:50 +00:00
|
|
|
# with options that depend on this runtime, such as `-C profile-generate` or
|
|
|
|
# `-C instrument-coverage`). This may also be given a path to an existing build
|
|
|
|
# of the profiling runtime library from LLVM's compiler-rt.
|
2020-10-25 12:13:14 +00:00
|
|
|
# This option will override the same option under [build] section.
|
2021-02-23 18:01:39 +00:00
|
|
|
#profiler = build.profiler (bool)
|
2020-10-25 12:13:14 +00:00
|
|
|
|
2023-07-03 01:16:44 +00:00
|
|
|
# This option supports enable `rpath` in each target independently,
|
2023-05-05 09:18:42 +00:00
|
|
|
# and will override the same option under [rust] section. It only works on Unix platforms
|
|
|
|
#rpath = rust.rpath (bool)
|
|
|
|
|
2017-08-22 21:24:29 +00:00
|
|
|
# Force static or dynamic linkage of the standard library for this target. If
|
|
|
|
# this target is a host for rustc, this will also affect the linkage of the
|
|
|
|
# compiler itself. This is useful for building rustc on targets that normally
|
|
|
|
# only use static libraries. If unset, the target's default linkage is used.
|
2021-02-23 18:01:39 +00:00
|
|
|
#crt-static = <platform-specific> (bool)
|
2017-08-22 21:24:29 +00:00
|
|
|
|
2020-06-17 00:00:00 +00:00
|
|
|
# The root location of the musl installation directory. The library directory
|
2016-09-07 02:49:02 +00:00
|
|
|
# will also need to contain libunwind.a for an unwinding implementation. Note
|
2020-06-17 00:00:00 +00:00
|
|
|
# that this option only makes sense for musl targets that produce statically
|
2021-02-23 18:01:39 +00:00
|
|
|
# linked binaries.
|
|
|
|
#musl-root = build.musl-root (path)
|
2017-01-24 22:37:04 +00:00
|
|
|
|
2020-06-17 00:00:00 +00:00
|
|
|
# The full path to the musl libdir.
|
|
|
|
#musl-libdir = musl-root/lib
|
|
|
|
|
2021-02-21 07:18:56 +00:00
|
|
|
# The root location of the `wasm32-wasi` sysroot. Only used for the
|
|
|
|
# `wasm32-wasi` target. If you are building wasm32-wasi target, make sure to
|
|
|
|
# create a `[target.wasm32-wasi]` section and move this field there.
|
2021-02-23 18:01:39 +00:00
|
|
|
#wasi-root = <none> (path)
|
Add a new wasm32-unknown-wasi target
This commit adds a new wasm32-based target distributed through rustup,
supported in the standard library, and implemented in the compiler. The
`wasm32-unknown-wasi` target is intended to be a WebAssembly target
which matches the [WASI proposal recently announced.][LINK]. In summary
the WASI target is an effort to define a standard set of syscalls for
WebAssembly modules, allowing WebAssembly modules to not only be
portable across architectures but also be portable across environments
implementing this standard set of system calls.
The wasi target in libstd is still somewhat bare bones. This PR does not
fill out the filesystem, networking, threads, etc. Instead it only
provides the most basic of integration with the wasi syscalls, enabling
features like:
* `Instant::now` and `SystemTime::now` work
* `env::args` is hooked up
* `env::vars` will look up environment variables
* `println!` will print to standard out
* `process::{exit, abort}` should be hooked up appropriately
None of these APIs can work natively on the `wasm32-unknown-unknown`
target, but with the assumption of the WASI set of syscalls we're able
to provide implementations of these syscalls that engines can implement.
Currently the primary engine implementing wasi is [wasmtime], but more
will surely emerge!
In terms of future development of libstd, I think this is something
we'll probably want to discuss. The purpose of the WASI target is to
provide a standardized set of syscalls, but it's *also* to provide a
standard C sysroot for compiling C/C++ programs. This means it's
intended that functions like `read` and `write` are implemented for this
target with a relatively standard definition and implementation. It's
unclear, therefore, how we want to expose file descriptors and how we'll
want to implement system primitives. For example should `std::fs::File`
have a libc-based file descriptor underneath it? The raw wasi file
descriptor? We'll see! Currently these details are all intentionally
hidden and things we can change over time.
A `WasiFd` sample struct was added to the standard library as part of
this commit, but it's not currently used. It shows how all the wasi
syscalls could be ergonomically bound in Rust, and they offer a possible
implementation of primitives like `std::fs::File` if we bind wasi file
descriptors exactly.
Apart from the standard library, there's also the matter of how this
target is integrated with respect to its C standard library. The
reference sysroot, for example, provides managment of standard unix file
descriptors and also standard APIs like `open` (as opposed to the
relative `openat` inspiration for the wasi ssycalls). Currently the
standard library relies on the C sysroot symbols for operations such as
environment management, process exit, and `read`/`write` of stdio fds.
We want these operations in Rust to be interoperable with C if they're
used in the same process. Put another way, if Rust and C are linked into
the same WebAssembly binary they should work together, but that requires
that the same C standard library is used.
We also, however, want the `wasm32-unknown-wasi` target to be
usable-by-default with the Rust compiler without requiring a separate
toolchain to get downloaded and configured. With that in mind, there's
two modes of operation for the `wasm32-unknown-wasi` target:
1. By default the C standard library is statically provided inside of
`liblibc.rlib` distributed as part of the sysroot. This means that
you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're
good to go, a fully workable wasi binary pops out. This is
incompatible with linking in C code, however, which may be compiled
against a different sysroot than the Rust code was previously
compiled against. In this mode the default of `rust-lld` is used to
link binaries.
2. For linking with C code, the `-C target-feature=-crt-static` flag
needs to be passed. This takes inspiration from the musl target for
this flag, but the idea is that you're no longer using the provided
static C runtime, but rather one will be provided externally. This
flag is intended to also get coupled with an external `clang`
compiler configured with its own sysroot. Therefore you'll typically
use this flag with `-C linker=/path/to/clang-script-wrapper`. Using
this mode the Rust code will continue to reference standard C
symbols, but the definition will be pulled in by the linker configured.
Alright so that's all the current state of this PR. I suspect we'll
definitely want to discuss this before landing of course! This PR is
coupled with libc changes as well which I'll be posting shortly.
[LINK]:
[wasmtime]:
2019-02-13 18:02:22 +00:00
|
|
|
|
2017-08-26 22:01:48 +00:00
|
|
|
# Used in testing for configuring where the QEMU images are located, you
|
|
|
|
# probably don't want to use this.
|
2021-02-23 18:01:39 +00:00
|
|
|
#qemu-rootfs = <none> (path)
|
2017-08-26 22:01:48 +00:00
|
|
|
|
2022-08-01 22:12:07 +00:00
|
|
|
# Skip building the `std` library for this target. Enabled by default for
|
|
|
|
# target triples containing `-none`, `nvptx`, `switch`, or `-uefi`.
|
|
|
|
#no-std = <platform-specific> (bool)
|
|
|
|
|
2017-01-24 22:37:04 +00:00
|
|
|
# =============================================================================
|
|
|
|
# Distribution options
|
|
|
|
#
|
|
|
|
# These options are related to distribution, mostly for the Rust project itself.
|
|
|
|
# You probably won't need to concern yourself with any of these options
|
|
|
|
# =============================================================================
|
|
|
|
[dist]
|
|
|
|
|
|
|
|
# This is the folder of artifacts that the build system will sign. All files in
|
|
|
|
# this directory will be signed with the default gpg key using the system `gpg`
|
|
|
|
# binary. The `asc` and `sha256` files will all be output into the standard dist
|
|
|
|
# output folder (currently `build/dist`)
|
|
|
|
#
|
|
|
|
# This folder should be populated ahead of time before the build system is
|
|
|
|
# invoked.
|
2021-02-23 18:01:39 +00:00
|
|
|
#sign-folder = <none> (path)
|
2017-01-24 22:37:04 +00:00
|
|
|
|
|
|
|
# The remote address that all artifacts will eventually be uploaded to. The
|
|
|
|
# build system generates manifests which will point to these urls, and for the
|
|
|
|
# manifests to be correct they'll have to have the right URLs encoded.
|
|
|
|
#
|
|
|
|
# Note that this address should not contain a trailing slash as file names will
|
|
|
|
# be appended to it.
|
2021-02-23 18:01:39 +00:00
|
|
|
#upload-addr = <none> (URL)
|
2017-05-18 20:48:14 +00:00
|
|
|
|
|
|
|
# Whether to build a plain source tarball to upload
|
|
|
|
# We disable that on Windows not to override the one already uploaded on S3
|
|
|
|
# as the one built on Windows will contain backslashes in paths causing problems
|
|
|
|
# on linux
|
|
|
|
#src-tarball = true
|
2018-09-30 17:14:27 +00:00
|
|
|
|
|
|
|
# Whether to allow failures when building tools
|
|
|
|
#missing-tools = false
|
2020-12-14 14:53:07 +00:00
|
|
|
|
|
|
|
# List of compression formats to use when generating dist tarballs. The list of
|
|
|
|
# formats is provided to rust-installer, which must support all of them.
|
2021-02-23 18:01:39 +00:00
|
|
|
#
|
|
|
|
# This list must be non-empty.
|
2020-12-14 14:53:07 +00:00
|
|
|
#compression-formats = ["gz", "xz"]
|
2023-03-14 14:30:42 +00:00
|
|
|
|
|
|
|
# How much time should be spent compressing the tarballs. The better the
|
|
|
|
# compression profile, the longer compression will take.
|
|
|
|
#
|
|
|
|
# Available options: fast, balanced, best
|
2023-03-21 08:44:42 +00:00
|
|
|
#compression-profile = "fast"
|
2023-07-15 12:56:07 +00:00
|
|
|
|
|
|
|
# Copy the linker, DLLs, and various libraries from MinGW into the rustc toolchain.
|
|
|
|
# Only applies when the host or target is pc-windows-gnu.
|
|
|
|
#include-mingw-linker = true
|