Auto merge of #137081 - Shourya742:2025-02-15-change-config.toml-to-bootstrap.toml, r=onur-ozkan,jieyouxu,kobzol
change config.toml to bootstrap.toml Currently, both Bootstrap and Cargo uses same name as their configuration file, which can be confusing. This PR is based on a discussion to rename `config.toml` to `bootstrap.toml` for Bootstrap. Closes: https://github.com/rust-lang/rust/issues/126875. I have split the PR into atomic commits to make it easier to review. Once the changes are finalized, I will squash them. I am particularly concerned about the changes made to modules that are not part of Bootstrap. How should we handle those changes? Should we ping the respective maintainers?
This commit is contained in:
bors
commit
8279176ccd
125 changed files with 570 additions and 532 deletions
2
.github/ISSUE_TEMPLATE/bootstrap.md
vendored
2
.github/ISSUE_TEMPLATE/bootstrap.md
vendored
|
|
@ -32,7 +32,7 @@ Describe what you expected to happen.
|
|||
Describe what actually happened.
|
||||
-->
|
||||
|
||||
### Bootstrap configuration (config.toml)
|
||||
### Bootstrap configuration (bootstrap.toml)
|
||||
```toml
|
||||
<config>
|
||||
```
|
||||
|
|
|
|||
3
.gitignore
vendored
3
.gitignore
vendored
|
|
@ -1,6 +1,6 @@
|
|||
# This file should only ignore things that are generated during a `x.py` build,
|
||||
# generated by common IDEs, and optional files controlled by the user that
|
||||
# affect the build (such as config.toml).
|
||||
# affect the build (such as bootstrap.toml).
|
||||
# In particular, things like `mir_dump` should not be listed here; they are only
|
||||
# created during manual debugging and many people like to clean up instead of
|
||||
# having git ignore such leftovers. You can use `.git/info/exclude` to
|
||||
|
|
@ -34,6 +34,7 @@ Session.vim
|
|||
!/tests/run-make/thumb-none-qemu/example/.cargo
|
||||
|
||||
## Configuration
|
||||
/bootstrap.toml
|
||||
/config.toml
|
||||
/Makefile
|
||||
config.mk
|
||||
|
|
|
|||
3
.ignore
3
.ignore
|
|
@ -1,2 +1,3 @@
|
|||
# Make vscode *not* count `config.toml` as ignored, so it is included in search
|
||||
# Make vscode *not* count `bootstrap.toml` and `config.toml` as ignored, so it is included in search
|
||||
!/bootstrap.toml
|
||||
!/config.toml
|
||||
|
|
|
|||
10
INSTALL.md
10
INSTALL.md
|
|
@ -6,9 +6,9 @@ If you just want to install Rust, check out the [README.md](README.md) instead.*
|
|||
|
||||
The Rust build system uses a Python script called `x.py` to build the compiler,
|
||||
which manages the bootstrapping process. It lives at the root of the project.
|
||||
It also uses a file named `config.toml` to determine various configuration
|
||||
It also uses a file named `bootstrap.toml` to determine various configuration
|
||||
settings for the build. You can see a full list of options in
|
||||
`config.example.toml`.
|
||||
`bootstrap.example.toml`.
|
||||
|
||||
The `x.py` command can be run directly on most Unix systems in the following
|
||||
format:
|
||||
|
|
@ -115,7 +115,7 @@ See [the rustc-dev-guide for more info][sysllvm].
|
|||
|
||||
This project provides a configure script and makefile (the latter of which just
|
||||
invokes `x.py`). `./configure` is the recommended way to programmatically
|
||||
generate a `config.toml`. `make` is not recommended (we suggest using `x.py`
|
||||
generate a `bootstrap.toml`. `make` is not recommended (we suggest using `x.py`
|
||||
directly), but it is supported and we try not to break it unnecessarily.
|
||||
|
||||
```sh
|
||||
|
|
@ -123,7 +123,7 @@ directly), but it is supported and we try not to break it unnecessarily.
|
|||
make && sudo make install
|
||||
```
|
||||
|
||||
`configure` generates a `config.toml` which can also be used with normal `x.py`
|
||||
`configure` generates a `bootstrap.toml` which can also be used with normal `x.py`
|
||||
invocations.
|
||||
|
||||
## Building on Windows
|
||||
|
|
@ -255,7 +255,7 @@ Windows build triples are:
|
|||
- `x86_64-pc-windows-msvc`
|
||||
|
||||
The build triple can be specified by either specifying `--build=<triple>` when
|
||||
invoking `x.py` commands, or by creating a `config.toml` file (as described in
|
||||
invoking `x.py` commands, or by creating a `bootstrap.toml` file (as described in
|
||||
[Building on a Unix-like system](#building-on-a-unix-like-system)), and passing
|
||||
`--set build.build=<triple>` to `./configure`.
|
||||
|
||||
|
|
|
|||
|
|
@ -2282,7 +2282,7 @@ Compatibility Notes
|
|||
- [Cargo denies `CARGO_HOME` in the `[env]` configuration table. Cargo itself doesn't pick up this value, but recursive calls to cargo would, which was not intended.](https://github.com/rust-lang/cargo/pull/11644/)
|
||||
- [Debuginfo for build dependencies is now off if not explicitly set. This is expected to improve the overall build time.](https://github.com/rust-lang/cargo/pull/11252/)
|
||||
- [The Rust distribution no longer always includes rustdoc](https://github.com/rust-lang/rust/pull/106886)
|
||||
If `tools = [...]` is set in config.toml, we will respect a missing rustdoc in that list. By
|
||||
If `tools = [...]` is set in bootstrap.toml, we will respect a missing rustdoc in that list. By
|
||||
default rustdoc remains included. To retain the prior behavior explicitly add `"rustdoc"` to the
|
||||
list.
|
||||
|
||||
|
|
@ -5268,7 +5268,7 @@ related tools.
|
|||
|
||||
- [Building `rustc` from source now uses `ninja` by default over `make`.][74922]
|
||||
You can continue building with `make` by setting `ninja=false` in
|
||||
your `config.toml`.
|
||||
your `bootstrap.toml`.
|
||||
- [cg_llvm: `fewer_names` in `uncached_llvm_type`][76030]
|
||||
- [Made `ensure_sufficient_stack()` non-generic][76680]
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ path = [
|
|||
"Cargo.lock",
|
||||
"Cargo.toml",
|
||||
"CODE_OF_CONDUCT.md",
|
||||
"config.example.toml",
|
||||
"bootstrap.example.toml",
|
||||
"configure",
|
||||
"CONTRIBUTING.md",
|
||||
"COPYRIGHT",
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
#
|
||||
# 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
|
||||
# `bootstrap.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.
|
||||
|
||||
|
|
@ -16,7 +16,7 @@
|
|||
# Use different pre-set defaults than the global defaults.
|
||||
#
|
||||
# See `src/bootstrap/defaults` for more information.
|
||||
# Note that this has no default value (x.py uses the defaults in `config.example.toml`).
|
||||
# Note that this has no default value (x.py uses the defaults in `bootstrap.example.toml`).
|
||||
#profile = <none>
|
||||
|
||||
# Keeps track of major changes made to this configuration.
|
||||
|
|
@ -346,7 +346,7 @@
|
|||
# Enable a build of the extended Rust tool set which is not only the compiler
|
||||
# but also tools such as Cargo. This will also produce "combined installers"
|
||||
# which are used to install Rust and Cargo together.
|
||||
# The `tools` (check `config.example.toml` to see its default value) option specifies
|
||||
# The `tools` (check `bootstrap.example.toml` to see its default value) option specifies
|
||||
# which tools should be built if `extended = true`.
|
||||
#
|
||||
# This is disabled by default.
|
||||
|
|
@ -389,7 +389,7 @@ top_level_options!(
|
|||
///
|
||||
/// This directory is what the virtual `/rustc/$hash` is translated back to,
|
||||
/// if Rust was built with path remapping to `/rustc/$hash` enabled
|
||||
/// (the `rust.remap-debuginfo` option in `config.toml`).
|
||||
/// (the `rust.remap-debuginfo` option in `bootstrap.toml`).
|
||||
real_rust_source_base_dir: Option<PathBuf> [TRACKED_NO_CRATE_HASH],
|
||||
|
||||
edition: Edition [TRACKED],
|
||||
|
|
|
|||
|
|
@ -163,7 +163,7 @@ compiler, which will then build the bootstrap binary written in Rust.
|
|||
|
||||
Because there are two separate codebases behind `x.py`, they need to
|
||||
be kept in sync. In particular, both `bootstrap.py` and the bootstrap binary
|
||||
parse `config.toml` and read the same command line arguments. `bootstrap.py`
|
||||
parse `bootstrap.toml` and read the same command line arguments. `bootstrap.py`
|
||||
keeps these in sync by setting various environment variables, and the
|
||||
programs sometimes have to add arguments that are explicitly ignored, to be
|
||||
read by the other.
|
||||
|
|
|
|||
|
|
@ -726,7 +726,7 @@ class RustBuild(object):
|
|||
|
||||
def should_fix_bins_and_dylibs(self):
|
||||
"""Whether or not `fix_bin_or_dylib` needs to be run; can only be True
|
||||
on NixOS or if config.toml has `build.patch-binaries-for-nix` set.
|
||||
on NixOS or if bootstrap.toml has `build.patch-binaries-for-nix` set.
|
||||
"""
|
||||
if self._should_fix_bins_and_dylibs is not None:
|
||||
return self._should_fix_bins_and_dylibs
|
||||
|
|
@ -775,7 +775,7 @@ class RustBuild(object):
|
|||
"The IN_NIX_SHELL environment variable is `{}`;".format(
|
||||
in_nix_shell
|
||||
),
|
||||
"you may need to set `patch-binaries-for-nix=true` in config.toml",
|
||||
"you may need to set `patch-binaries-for-nix=true` in bootstrap.toml",
|
||||
)
|
||||
|
||||
return is_nixos
|
||||
|
|
@ -884,7 +884,7 @@ class RustBuild(object):
|
|||
return os.path.join(self.build_dir, self.build, subdir)
|
||||
|
||||
def get_toml(self, key, section=None):
|
||||
"""Returns the value of the given key in config.toml, otherwise returns None
|
||||
"""Returns the value of the given key in bootstrap.toml, otherwise returns None
|
||||
|
||||
>>> rb = RustBuild()
|
||||
>>> rb.config_toml = 'key1 = "value1"\\nkey2 = "value2"'
|
||||
|
|
@ -1250,17 +1250,23 @@ def bootstrap(args):
|
|||
"unless you put them in place manually."
|
||||
)
|
||||
|
||||
# Read from `--config`, then `RUST_BOOTSTRAP_CONFIG`, then `./config.toml`,
|
||||
# then `config.toml` in the root directory.
|
||||
# Read from `--config` first, followed by `RUST_BOOTSTRAP_CONFIG`.
|
||||
# If neither is set, check `./bootstrap.toml`, then `bootstrap.toml` in the root directory.
|
||||
# If those are unavailable, fall back to `./config.toml`, then `config.toml` for
|
||||
# backward compatibility.
|
||||
toml_path = args.config or os.getenv("RUST_BOOTSTRAP_CONFIG")
|
||||
using_default_path = toml_path is None
|
||||
if using_default_path:
|
||||
toml_path = "config.toml"
|
||||
toml_path = "bootstrap.toml"
|
||||
if not os.path.exists(toml_path):
|
||||
toml_path = os.path.join(rust_root, toml_path)
|
||||
toml_path = os.path.join(rust_root, "bootstrap.toml")
|
||||
if not os.path.exists(toml_path):
|
||||
toml_path = "config.toml"
|
||||
if not os.path.exists(toml_path):
|
||||
toml_path = os.path.join(rust_root, "config.toml")
|
||||
|
||||
# Give a hard error if `--config` or `RUST_BOOTSTRAP_CONFIG` are set to a missing path,
|
||||
# but not if `config.toml` hasn't been created.
|
||||
# but not if `bootstrap.toml` hasn't been created.
|
||||
if not using_default_path or os.path.exists(toml_path):
|
||||
with open(toml_path) as config:
|
||||
config_toml = config.read()
|
||||
|
|
@ -1278,7 +1284,9 @@ def bootstrap(args):
|
|||
# profiles to be renamed while maintaining back compatibility
|
||||
# Keep in sync with `profile_aliases` in config.rs
|
||||
profile_aliases = {"user": "dist"}
|
||||
include_file = "config.{}.toml".format(profile_aliases.get(profile) or profile)
|
||||
include_file = "bootstrap.{}.toml".format(
|
||||
profile_aliases.get(profile) or profile
|
||||
)
|
||||
include_dir = os.path.join(rust_root, "src", "bootstrap", "defaults")
|
||||
include_path = os.path.join(include_dir, include_file)
|
||||
|
||||
|
|
|
|||
|
|
@ -156,7 +156,7 @@ class ParseArgsInConfigure(unittest.TestCase):
|
|||
|
||||
|
||||
class GenerateAndParseConfig(unittest.TestCase):
|
||||
"""Test that we can serialize and deserialize a config.toml file"""
|
||||
"""Test that we can serialize and deserialize a bootstrap.toml file"""
|
||||
|
||||
def test_no_args(self):
|
||||
build = serialize_and_parse([])
|
||||
|
|
@ -206,11 +206,11 @@ class BuildBootstrap(unittest.TestCase):
|
|||
# problem in most cases, but there is a scenario where it would cause
|
||||
# the test to fail.
|
||||
#
|
||||
# When a custom local Cargo is configured in config.toml (with the
|
||||
# When a custom local Cargo is configured in bootstrap.toml (with the
|
||||
# build.cargo setting), no Cargo is downloaded to any location known by
|
||||
# bootstrap, and bootstrap relies on that setting to find it.
|
||||
#
|
||||
# In this test though we are not using the config.toml of the caller:
|
||||
# In this test though we are not using the bootstrap.toml of the caller:
|
||||
# we are generating a blank one instead. If we don't set build.cargo in
|
||||
# it, the test will have no way to find Cargo, failing the test.
|
||||
cargo_bin = os.environ.get("BOOTSTRAP_TEST_CARGO_BIN")
|
||||
|
|
|
|||
|
|
@ -367,8 +367,8 @@ if "--help" in sys.argv or "-h" in sys.argv:
|
|||
print("\t\t" + option.desc)
|
||||
print("")
|
||||
print("This configure script is a thin configuration shim over the true")
|
||||
print("configuration system, `config.toml`. You can explore the comments")
|
||||
print("in `config.example.toml` next to this configure script to see")
|
||||
print("configuration system, `bootstrap.toml`. You can explore the comments")
|
||||
print("in `bootstrap.example.toml` next to this configure script to see")
|
||||
print("more information about what each option is. Additionally you can")
|
||||
print("pass `--set` as an argument to set arbitrary key/value pairs")
|
||||
print("in the TOML configuration if desired")
|
||||
|
|
@ -567,8 +567,8 @@ def apply_args(known_args, option_checking, config):
|
|||
raise RuntimeError("unhandled option {}".format(option.name))
|
||||
|
||||
|
||||
# "Parse" the `config.example.toml` file into the various sections, and we'll
|
||||
# use this as a template of a `config.toml` to write out which preserves
|
||||
# "Parse" the `bootstrap.example.toml` file into the various sections, and we'll
|
||||
# use this as a template of a `bootstrap.toml` to write out which preserves
|
||||
# all the various comments and whatnot.
|
||||
#
|
||||
# Note that the `target` section is handled separately as we'll duplicate it
|
||||
|
|
@ -581,7 +581,7 @@ def parse_example_config(known_args, config):
|
|||
targets = {}
|
||||
top_level_keys = []
|
||||
|
||||
with open(rust_dir + "/config.example.toml") as example_config:
|
||||
with open(rust_dir + "/bootstrap.example.toml") as example_config:
|
||||
example_lines = example_config.read().split("\n")
|
||||
for line in example_lines:
|
||||
if cur_section is None:
|
||||
|
|
@ -755,8 +755,8 @@ def quit_if_file_exists(file):
|
|||
|
||||
|
||||
if __name__ == "__main__":
|
||||
# If 'config.toml' already exists, exit the script at this point
|
||||
quit_if_file_exists("config.toml")
|
||||
# If 'bootstrap.toml' already exists, exit the script at this point
|
||||
quit_if_file_exists("bootstrap.toml")
|
||||
|
||||
if "GITHUB_ACTIONS" in os.environ:
|
||||
print("::group::Configure the build")
|
||||
|
|
@ -766,11 +766,11 @@ if __name__ == "__main__":
|
|||
p("")
|
||||
section_order, sections, targets = parse_args(sys.argv[1:])
|
||||
|
||||
# Now that we've built up our `config.toml`, write it all out in the same
|
||||
# Now that we've built up our `bootstrap.toml`, write it all out in the same
|
||||
# order that we read it in.
|
||||
p("")
|
||||
p("writing `config.toml` in current directory")
|
||||
with bootstrap.output("config.toml") as f:
|
||||
p("writing `bootstrap.toml` in current directory")
|
||||
with bootstrap.output("bootstrap.toml") as f:
|
||||
write_config_toml(f, section_order, targets, sections)
|
||||
|
||||
with bootstrap.output("Makefile") as f:
|
||||
|
|
|
|||
|
|
@ -77,14 +77,14 @@ fn main() {
|
|||
check_version(&config)
|
||||
};
|
||||
|
||||
// NOTE: Since `./configure` generates a `config.toml`, distro maintainers will see the
|
||||
// NOTE: Since `./configure` generates a `bootstrap.toml`, distro maintainers will see the
|
||||
// changelog warning, not the `x.py setup` message.
|
||||
let suggest_setup = config.config.is_none() && !matches!(config.cmd, Subcommand::Setup { .. });
|
||||
if suggest_setup {
|
||||
println!("WARNING: you have not made a `config.toml`");
|
||||
println!("WARNING: you have not made a `bootstrap.toml`");
|
||||
println!(
|
||||
"HELP: consider running `./x.py setup` or copying `config.example.toml` by running \
|
||||
`cp config.example.toml config.toml`"
|
||||
"HELP: consider running `./x.py setup` or copying `bootstrap.example.toml` by running \
|
||||
`cp bootstrap.example.toml bootstrap.toml`"
|
||||
);
|
||||
} else if let Some(suggestion) = &changelog_suggestion {
|
||||
println!("{suggestion}");
|
||||
|
|
@ -98,10 +98,10 @@ fn main() {
|
|||
Build::new(config).build();
|
||||
|
||||
if suggest_setup {
|
||||
println!("WARNING: you have not made a `config.toml`");
|
||||
println!("WARNING: you have not made a `bootstrap.toml`");
|
||||
println!(
|
||||
"HELP: consider running `./x.py setup` or copying `config.example.toml` by running \
|
||||
`cp config.example.toml config.toml`"
|
||||
"HELP: consider running `./x.py setup` or copying `bootstrap.example.toml` by running \
|
||||
`cp bootstrap.example.toml bootstrap.toml`"
|
||||
);
|
||||
} else if let Some(suggestion) = &changelog_suggestion {
|
||||
println!("{suggestion}");
|
||||
|
|
@ -160,7 +160,7 @@ fn check_version(config: &Config) -> Option<String> {
|
|||
}
|
||||
|
||||
// Always try to use `change-id` from .last-warned-change-id first. If it doesn't exist,
|
||||
// then use the one from the config.toml. This way we never show the same warnings
|
||||
// then use the one from the bootstrap.toml. This way we never show the same warnings
|
||||
// more than once.
|
||||
if let Ok(t) = fs::read_to_string(&warned_id_path) {
|
||||
let last_warned_id = usize::from_str(&t)
|
||||
|
|
@ -185,16 +185,18 @@ fn check_version(config: &Config) -> Option<String> {
|
|||
|
||||
msg.push_str("NOTE: to silence this warning, ");
|
||||
msg.push_str(&format!(
|
||||
"update `config.toml` to use `change-id = {latest_change_id}` instead"
|
||||
"update `bootstrap.toml` to use `change-id = {latest_change_id}` instead"
|
||||
));
|
||||
|
||||
if io::stdout().is_terminal() {
|
||||
t!(fs::write(warned_id_path, latest_change_id.to_string()));
|
||||
}
|
||||
} else {
|
||||
msg.push_str("WARNING: The `change-id` is missing in the `config.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.\n");
|
||||
msg.push_str("WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.\n");
|
||||
msg.push_str("NOTE: to silence this warning, ");
|
||||
msg.push_str(&format!("add `change-id = {latest_change_id}` at the top of `config.toml`"));
|
||||
msg.push_str(&format!(
|
||||
"add `change-id = {latest_change_id}` at the top of `bootstrap.toml`"
|
||||
));
|
||||
};
|
||||
|
||||
Some(msg)
|
||||
|
|
|
|||
|
|
@ -425,7 +425,7 @@ fn copy_self_contained_objects(
|
|||
} else if target.contains("-wasi") {
|
||||
let srcdir = builder.wasi_libdir(target).unwrap_or_else(|| {
|
||||
panic!(
|
||||
"Target {:?} does not have a \"wasi-root\" key in Config.toml \
|
||||
"Target {:?} does not have a \"wasi-root\" key in bootstrap.toml \
|
||||
or `$WASI_SDK_PATH` set",
|
||||
target.triple
|
||||
)
|
||||
|
|
@ -1294,7 +1294,7 @@ pub fn rustc_cargo_env(
|
|||
.env("CFG_VERSION", builder.rust_version());
|
||||
|
||||
// Some tools like Cargo detect their own git information in build scripts. When omit-git-hash
|
||||
// is enabled in config.toml, we pass this environment variable to tell build scripts to avoid
|
||||
// is enabled in bootstrap.toml, we pass this environment variable to tell build scripts to avoid
|
||||
// detecting git information on their own.
|
||||
if builder.config.omit_git_hash {
|
||||
cargo.env("CFG_OMIT_GIT_HASH", "1");
|
||||
|
|
@ -1538,7 +1538,7 @@ fn is_codegen_cfg_needed(path: &TaskPath, run: &RunConfig<'_>) -> bool {
|
|||
{
|
||||
run.builder.info(
|
||||
"WARNING: no codegen-backends config matched the requested path to build a codegen backend. \
|
||||
HELP: add backend to codegen-backends in config.toml.",
|
||||
HELP: add backend to codegen-backends in bootstrap.toml.",
|
||||
);
|
||||
return true;
|
||||
}
|
||||
|
|
@ -1550,7 +1550,7 @@ fn is_codegen_cfg_needed(path: &TaskPath, run: &RunConfig<'_>) -> bool {
|
|||
impl Step for CodegenBackend {
|
||||
type Output = ();
|
||||
const ONLY_HOSTS: bool = true;
|
||||
/// Only the backends specified in the `codegen-backends` entry of `config.toml` are built.
|
||||
/// Only the backends specified in the `codegen-backends` entry of `bootstrap.toml` are built.
|
||||
const DEFAULT: bool = true;
|
||||
|
||||
fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> {
|
||||
|
|
|
|||
|
|
@ -1000,9 +1000,9 @@ impl Step for PlainSourceTarball {
|
|||
let src_files = [
|
||||
// tidy-alphabetical-start
|
||||
".gitmodules",
|
||||
"bootstrap.example.toml",
|
||||
"Cargo.lock",
|
||||
"Cargo.toml",
|
||||
"config.example.toml",
|
||||
"configure",
|
||||
"CONTRIBUTING.md",
|
||||
"COPYRIGHT",
|
||||
|
|
|
|||
|
|
@ -1218,7 +1218,7 @@ impl Step for RustcBook {
|
|||
cmd.env("RUSTC_BOOTSTRAP", "1");
|
||||
|
||||
// If the lib directories are in an unusual location (changed in
|
||||
// config.toml), then this needs to explicitly update the dylib search
|
||||
// bootstrap.toml), then this needs to explicitly update the dylib search
|
||||
// path.
|
||||
builder.add_rustc_lib_path(self.compiler, &mut cmd);
|
||||
let doc_generator_guard = builder.msg(
|
||||
|
|
|
|||
|
|
@ -85,11 +85,11 @@ fn install_sh(
|
|||
} else {
|
||||
assert!(
|
||||
is_dir_writable_for_user(&prefix),
|
||||
"User doesn't have write access on `install.prefix` path in the `config.toml`.",
|
||||
"User doesn't have write access on `install.prefix` path in the `bootstrap.toml`.",
|
||||
);
|
||||
assert!(
|
||||
is_dir_writable_for_user(&sysconfdir),
|
||||
"User doesn't have write access on `install.sysconfdir` path in `config.toml`."
|
||||
"User doesn't have write access on `install.sysconfdir` path in `bootstrap.toml`."
|
||||
);
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -350,7 +350,7 @@ impl Step for Llvm {
|
|||
(true, true) => "RelWithDebInfo",
|
||||
};
|
||||
|
||||
// NOTE: remember to also update `config.example.toml` when changing the
|
||||
// NOTE: remember to also update `bootstrap.example.toml` when changing the
|
||||
// defaults!
|
||||
let llvm_targets = match &builder.config.llvm_targets {
|
||||
Some(s) => s,
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ pub fn perf(builder: &Builder<'_>, args: &PerfArgs) {
|
|||
};
|
||||
if is_profiling && builder.build.config.rust_debuginfo_level_rustc == DebuginfoLevel::None {
|
||||
builder.info(r#"WARNING: You are compiling rustc without debuginfo, this will make profiling less useful.
|
||||
Consider setting `rust.debuginfo-level = 1` in `config.toml`."#);
|
||||
Consider setting `rust.debuginfo-level = 1` in `bootstrap.toml`."#);
|
||||
}
|
||||
|
||||
let compiler = builder.compiler(builder.top_stage, builder.config.build);
|
||||
|
|
|
|||
|
|
@ -35,10 +35,10 @@ impl Step for BuildManifest {
|
|||
// (https://github.com/rust-lang/promote-release).
|
||||
let mut cmd = builder.tool_cmd(Tool::BuildManifest);
|
||||
let sign = builder.config.dist_sign_folder.as_ref().unwrap_or_else(|| {
|
||||
panic!("\n\nfailed to specify `dist.sign-folder` in `config.toml`\n\n")
|
||||
panic!("\n\nfailed to specify `dist.sign-folder` in `bootstrap.toml`\n\n")
|
||||
});
|
||||
let addr = builder.config.dist_upload_addr.as_ref().unwrap_or_else(|| {
|
||||
panic!("\n\nfailed to specify `dist.upload-addr` in `config.toml`\n\n")
|
||||
panic!("\n\nfailed to specify `dist.upload-addr` in `bootstrap.toml`\n\n")
|
||||
});
|
||||
|
||||
let today = command("date").arg("+%Y-%m-%d").run_capture_stdout(builder).stdout();
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@
|
|||
//!
|
||||
//! These are build-and-run steps for `./x.py setup`, which allows quickly setting up the directory
|
||||
//! for modifying, building, and running the compiler and library. Running arbitrary configuration
|
||||
//! allows setting up things that cannot be simply captured inside the config.toml, in addition to
|
||||
//! leading people away from manually editing most of the config.toml values.
|
||||
//! allows setting up things that cannot be simply captured inside the bootstrap.toml, in addition to
|
||||
//! leading people away from manually editing most of the bootstrap.toml values.
|
||||
|
||||
use std::env::consts::EXE_SUFFIX;
|
||||
use std::fmt::Write as _;
|
||||
|
|
@ -37,7 +37,7 @@ static PROFILE_DIR: &str = "src/bootstrap/defaults";
|
|||
|
||||
impl Profile {
|
||||
fn include_path(&self, src_path: &Path) -> PathBuf {
|
||||
PathBuf::from(format!("{}/{PROFILE_DIR}/config.{}.toml", src_path.display(), self))
|
||||
PathBuf::from(format!("{}/{PROFILE_DIR}/bootstrap.{}.toml", src_path.display(), self))
|
||||
}
|
||||
|
||||
pub fn all() -> impl Iterator<Item = Self> {
|
||||
|
|
@ -53,7 +53,7 @@ impl Profile {
|
|||
Compiler => "Contribute to the compiler itself",
|
||||
Tools => "Contribute to tools which depend on the compiler, but do not modify it directly (e.g. rustdoc, clippy, miri)",
|
||||
Dist => "Install Rust from source",
|
||||
None => "Do not modify `config.toml`"
|
||||
None => "Do not modify `bootstrap.toml`"
|
||||
}
|
||||
.to_string()
|
||||
}
|
||||
|
|
@ -117,7 +117,7 @@ impl Step for Profile {
|
|||
return;
|
||||
}
|
||||
|
||||
let path = &run.builder.config.config.clone().unwrap_or(PathBuf::from("config.toml"));
|
||||
let path = &run.builder.config.config.clone().unwrap_or(PathBuf::from("bootstrap.toml"));
|
||||
if path.exists() {
|
||||
eprintln!();
|
||||
eprintln!(
|
||||
|
|
@ -203,7 +203,7 @@ pub fn setup(config: &Config, profile: Profile) {
|
|||
)
|
||||
}
|
||||
|
||||
let path = &config.config.clone().unwrap_or(PathBuf::from("config.toml"));
|
||||
let path = &config.config.clone().unwrap_or(PathBuf::from("bootstrap.toml"));
|
||||
setup_config_toml(path, profile, config);
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -1119,7 +1119,7 @@ impl Step for Tidy {
|
|||
"\
|
||||
ERROR: no `rustfmt` binary found in {PATH}
|
||||
INFO: `rust.channel` is currently set to \"{CHAN}\"
|
||||
HELP: if you are testing a beta branch, set `rust.channel` to \"beta\" in the `config.toml` file
|
||||
HELP: if you are testing a beta branch, set `rust.channel` to \"beta\" in the `bootstrap.toml` file
|
||||
HELP: to skip test's attempt to check tidiness, pass `--skip src/tools/tidy` to `x.py test`",
|
||||
PATH = inferred_rustfmt_dir.display(),
|
||||
CHAN = builder.config.channel,
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ impl Step for ToolStateCheck {
|
|||
/// Checks tool state status.
|
||||
///
|
||||
/// This is intended to be used in the `checktools.sh` script. To use
|
||||
/// this, set `save-toolstates` in `config.toml` so that tool status will
|
||||
/// this, set `save-toolstates` in `bootstrap.toml` so that tool status will
|
||||
/// be saved to a JSON file. Then, run `x.py test --no-fail-fast` for all
|
||||
/// of the tools to populate the JSON file. After that is done, this
|
||||
/// command can be run to check for any status failures, and exits with an
|
||||
|
|
@ -254,7 +254,7 @@ impl Builder<'_> {
|
|||
/// Updates the actual toolstate of a tool.
|
||||
///
|
||||
/// The toolstates are saved to the file specified by the key
|
||||
/// `rust.save-toolstates` in `config.toml`. If unspecified, nothing will be
|
||||
/// `rust.save-toolstates` in `bootstrap.toml`. If unspecified, nothing will be
|
||||
/// done. The file is updated immediately after this function completes.
|
||||
pub fn save_toolstate(&self, tool: &str, state: ToolState) {
|
||||
use std::io::Write;
|
||||
|
|
|
|||
|
|
@ -215,7 +215,7 @@ impl Cargo {
|
|||
// dynamic libraries. We use this by default on Unix platforms to ensure
|
||||
// that our nightlies behave the same on Windows, that is they work out
|
||||
// of the box. This can be disabled by setting `rpath = false` in `[rust]`
|
||||
// table of `config.toml`
|
||||
// table of `bootstrap.toml`
|
||||
//
|
||||
// Ok, so the astute might be wondering "why isn't `-C rpath` used
|
||||
// here?" and that is indeed a good question to ask. This codegen
|
||||
|
|
|
|||
|
|
@ -31,9 +31,9 @@ mod cargo;
|
|||
mod tests;
|
||||
|
||||
/// Builds and performs different [`Self::kind`]s of stuff and actions, taking
|
||||
/// into account build configuration from e.g. config.toml.
|
||||
/// into account build configuration from e.g. bootstrap.toml.
|
||||
pub struct Builder<'a> {
|
||||
/// Build configuration from e.g. config.toml.
|
||||
/// Build configuration from e.g. bootstrap.toml.
|
||||
pub build: &'a Build,
|
||||
|
||||
/// The stage to use. Either implicitly determined based on subcommand, or
|
||||
|
|
@ -332,7 +332,7 @@ impl PathSet {
|
|||
}
|
||||
|
||||
const PATH_REMAP: &[(&str, &[&str])] = &[
|
||||
// config.toml uses `rust-analyzer-proc-macro-srv`, but the
|
||||
// bootstrap.toml uses `rust-analyzer-proc-macro-srv`, but the
|
||||
// actual path is `proc-macro-srv-cli`
|
||||
("rust-analyzer-proc-macro-srv", &["src/tools/rust-analyzer/crates/proc-macro-srv-cli"]),
|
||||
// Make `x test tests` function the same as `x t tests/*`
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
//! Serialized configuration of a build.
|
||||
//!
|
||||
//! This module implements parsing `config.toml` configuration files to tweak
|
||||
//! This module implements parsing `bootstrap.toml` configuration files to tweak
|
||||
//! how the build runs.
|
||||
|
||||
use std::cell::{Cell, RefCell};
|
||||
|
|
@ -64,7 +64,7 @@ macro_rules! check_ci_llvm {
|
|||
/// useful in scenarios where developers want to see how the tarball sources were
|
||||
/// generated.
|
||||
///
|
||||
/// We also use this file to compare the host's config.toml against the CI rustc builder
|
||||
/// We also use this file to compare the host's bootstrap.toml against the CI rustc builder
|
||||
/// configuration to detect any incompatible options.
|
||||
pub(crate) const BUILDER_CONFIG_FILENAME: &str = "builder-config";
|
||||
|
||||
|
|
@ -184,12 +184,12 @@ pub enum GccCiMode {
|
|||
|
||||
/// Global configuration for the entire build and/or bootstrap.
|
||||
///
|
||||
/// This structure is parsed from `config.toml`, and some of the fields are inferred from `git` or build-time parameters.
|
||||
/// This structure is parsed from `bootstrap.toml`, and some of the fields are inferred from `git` or build-time parameters.
|
||||
///
|
||||
/// Note that this structure is not decoded directly into, but rather it is
|
||||
/// filled out from the decoded forms of the structs below. For documentation
|
||||
/// each field, see the corresponding fields in
|
||||
/// `config.example.toml`.
|
||||
/// `bootstrap.example.toml`.
|
||||
#[derive(Default, Clone)]
|
||||
pub struct Config {
|
||||
pub change_id: Option<usize>,
|
||||
|
|
@ -235,7 +235,7 @@ pub struct Config {
|
|||
pub keep_stage: Vec<u32>,
|
||||
pub keep_stage_std: Vec<u32>,
|
||||
pub src: PathBuf,
|
||||
/// defaults to `config.toml`
|
||||
/// defaults to `bootstrap.toml`
|
||||
pub config: Option<PathBuf>,
|
||||
pub jobs: Option<u32>,
|
||||
pub cmd: Subcommand,
|
||||
|
|
@ -470,7 +470,7 @@ impl std::str::FromStr for SplitDebuginfo {
|
|||
|
||||
impl SplitDebuginfo {
|
||||
/// Returns the default `-Csplit-debuginfo` value for the current target. See the comment for
|
||||
/// `rust.split-debuginfo` in `config.example.toml`.
|
||||
/// `rust.split-debuginfo` in `bootstrap.example.toml`.
|
||||
fn default_for_platform(target: TargetSelection) -> Self {
|
||||
if target.contains("apple") {
|
||||
SplitDebuginfo::Unpacked
|
||||
|
|
@ -677,7 +677,7 @@ impl Target {
|
|||
target
|
||||
}
|
||||
}
|
||||
/// Structure of the `config.toml` file that configuration is read from.
|
||||
/// Structure of the `bootstrap.toml` file that configuration is read from.
|
||||
///
|
||||
/// This structure uses `Decodable` to automatically decode a TOML configuration
|
||||
/// file into this format, and then this is traversed and written into the above
|
||||
|
|
@ -1485,26 +1485,35 @@ impl Config {
|
|||
|
||||
config.stage0_metadata = build_helper::stage0_parser::parse_stage0_file();
|
||||
|
||||
// Find configuration file, with the following cascading fallback (first match wins):
|
||||
// - `--config <path>`
|
||||
// - `RUST_BOOTSTRAP_CONFIG`
|
||||
// - `./config.toml`
|
||||
// - `config.toml` in the root directory.
|
||||
// Locate the configuration file using the following priority (first match wins):
|
||||
// 1. `--config <path>` (explicit flag)
|
||||
// 2. `RUST_BOOTSTRAP_CONFIG` environment variable
|
||||
// 3. `./bootstrap.toml` (local file)
|
||||
// 4. `<root>/bootstrap.toml`
|
||||
// 5. `./config.toml` (fallback for backward compatibility)
|
||||
// 6. `<root>/config.toml`
|
||||
let toml_path = flags
|
||||
.config
|
||||
.clone()
|
||||
.or_else(|| env::var_os("RUST_BOOTSTRAP_CONFIG").map(PathBuf::from));
|
||||
let using_default_path = toml_path.is_none();
|
||||
let mut toml_path = toml_path.unwrap_or_else(|| PathBuf::from("config.toml"));
|
||||
let mut toml_path = toml_path.unwrap_or_else(|| PathBuf::from("bootstrap.toml"));
|
||||
|
||||
if using_default_path && !toml_path.exists() {
|
||||
toml_path = config.src.join(toml_path);
|
||||
toml_path = config.src.join(PathBuf::from("bootstrap.toml"));
|
||||
if !toml_path.exists() {
|
||||
toml_path = PathBuf::from("config.toml");
|
||||
if !toml_path.exists() {
|
||||
toml_path = config.src.join(PathBuf::from("config.toml"));
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
let file_content = t!(fs::read_to_string(config.src.join("src/ci/channel")));
|
||||
let ci_channel = file_content.trim_end();
|
||||
|
||||
// Give a hard error if `--config` or `RUST_BOOTSTRAP_CONFIG` are set to a missing path,
|
||||
// but not if `config.toml` hasn't been created.
|
||||
// but not if `bootstrap.toml` hasn't been created.
|
||||
let mut toml = if !using_default_path || toml_path.exists() {
|
||||
config.config = Some(if cfg!(not(test)) {
|
||||
toml_path.canonicalize().unwrap()
|
||||
|
|
@ -1525,7 +1534,7 @@ impl Config {
|
|||
// same ones used to call the tests (if custom ones are not defined in the toml). If we
|
||||
// don't do that, bootstrap will use its own detection logic to find a suitable rustc
|
||||
// and Cargo, which doesn't work when the caller is specìfying a custom local rustc or
|
||||
// Cargo in their config.toml.
|
||||
// Cargo in their bootstrap.toml.
|
||||
let build = toml.build.get_or_insert_with(Default::default);
|
||||
build.rustc = build.rustc.take().or(std::env::var_os("RUSTC").map(|p| p.into()));
|
||||
build.cargo = build.cargo.take().or(std::env::var_os("CARGO").map(|p| p.into()));
|
||||
|
|
@ -1548,7 +1557,7 @@ impl Config {
|
|||
include_path.push("src");
|
||||
include_path.push("bootstrap");
|
||||
include_path.push("defaults");
|
||||
include_path.push(format!("config.{include}.toml"));
|
||||
include_path.push(format!("bootstrap.{include}.toml"));
|
||||
let included_toml = get_toml(&include_path).unwrap_or_else(|e| {
|
||||
eprintln!(
|
||||
"ERROR: Failed to parse default config profile at '{}': {e}",
|
||||
|
|
@ -2030,7 +2039,7 @@ impl Config {
|
|||
config.description = description;
|
||||
|
||||
// We need to override `rust.channel` if it's manually specified when using the CI rustc.
|
||||
// This is because if the compiler uses a different channel than the one specified in config.toml,
|
||||
// This is because if the compiler uses a different channel than the one specified in bootstrap.toml,
|
||||
// tests may fail due to using a different channel than the one used by the compiler during tests.
|
||||
if let Some(commit) = &config.download_rustc_commit {
|
||||
if is_user_configured_rust_channel {
|
||||
|
|
@ -2655,7 +2664,7 @@ impl Config {
|
|||
return None;
|
||||
},
|
||||
Err(e) => {
|
||||
eprintln!("ERROR: Failed to parse CI rustc config.toml: {e}");
|
||||
eprintln!("ERROR: Failed to parse CI rustc bootstrap.toml: {e}");
|
||||
exit!(2);
|
||||
},
|
||||
};
|
||||
|
|
@ -2818,7 +2827,7 @@ impl Config {
|
|||
///
|
||||
/// `relative_path` should be relative to the root of the git repository, not an absolute path.
|
||||
///
|
||||
/// This *does not* update the submodule if `config.toml` explicitly says
|
||||
/// This *does not* update the submodule if `bootstrap.toml` explicitly says
|
||||
/// not to, or if we're not in a git repository (like a plain source
|
||||
/// tarball). Typically [`crate::Build::require_submodule`] should be
|
||||
/// used instead to provide a nice error to the user if the submodule is
|
||||
|
|
@ -3042,7 +3051,9 @@ impl Config {
|
|||
}
|
||||
println!("ERROR: could not find commit hash for downloading rustc");
|
||||
println!("HELP: maybe your repository history is too shallow?");
|
||||
println!("HELP: consider setting `rust.download-rustc=false` in config.toml");
|
||||
println!(
|
||||
"HELP: consider setting `rust.download-rustc=false` in bootstrap.toml"
|
||||
);
|
||||
println!("HELP: or fetch enough history to include one upstream commit");
|
||||
crate::exit!(1);
|
||||
}
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ pub struct Flags {
|
|||
/// TOML configuration file for build
|
||||
pub config: Option<PathBuf>,
|
||||
#[arg(global = true, long, value_hint = clap::ValueHint::DirPath, value_name = "DIR")]
|
||||
/// Build directory, overrides `build.build-dir` in `config.toml`
|
||||
/// Build directory, overrides `build.build-dir` in `bootstrap.toml`
|
||||
pub build_dir: Option<PathBuf>,
|
||||
|
||||
#[arg(global = true, long, value_hint = clap::ValueHint::Other, value_name = "BUILD")]
|
||||
|
|
@ -173,7 +173,7 @@ pub struct Flags {
|
|||
#[arg(global = true)]
|
||||
/// paths for the subcommand
|
||||
pub paths: Vec<PathBuf>,
|
||||
/// override options in config.toml
|
||||
/// override options in bootstrap.toml
|
||||
#[arg(global = true, value_hint = clap::ValueHint::Other, long, value_name = "section.option=value")]
|
||||
pub set: Vec<String>,
|
||||
/// arguments passed to subcommands
|
||||
|
|
@ -448,7 +448,7 @@ pub enum Subcommand {
|
|||
/// Set up the environment for development
|
||||
#[command(long_about = format!(
|
||||
"\n
|
||||
x.py setup creates a `config.toml` which changes the defaults for x.py itself,
|
||||
x.py setup creates a `bootstrap.toml` which changes the defaults for x.py itself,
|
||||
as well as setting up a git pre-push hook, VS Code config and toolchain link.
|
||||
Arguments:
|
||||
This subcommand accepts a 'profile' to use for builds. For example:
|
||||
|
|
@ -461,7 +461,7 @@ Arguments:
|
|||
./x.py setup editor
|
||||
./x.py setup link", Profile::all_for_help(" ").trim_end()))]
|
||||
Setup {
|
||||
/// Either the profile for `config.toml` or another setup action.
|
||||
/// Either the profile for `bootstrap.toml` or another setup action.
|
||||
/// May be omitted to set up interactively
|
||||
#[arg(value_name = "<PROFILE>|hook|editor|link")]
|
||||
profile: Option<PathBuf>,
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ fn detect_src_and_out() {
|
|||
let expected_src = manifest_dir.ancestors().nth(2).unwrap();
|
||||
assert_eq!(&cfg.src, expected_src);
|
||||
|
||||
// test if build-dir was manually given in config.toml
|
||||
// test if build-dir was manually given in bootstrap.toml
|
||||
if let Some(custom_build_dir) = build_dir {
|
||||
assert_eq!(&cfg.out, Path::new(custom_build_dir));
|
||||
}
|
||||
|
|
@ -229,13 +229,15 @@ fn override_toml_duplicate() {
|
|||
#[test]
|
||||
fn profile_user_dist() {
|
||||
fn get_toml(file: &Path) -> Result<TomlConfig, toml::de::Error> {
|
||||
let contents =
|
||||
if file.ends_with("config.toml") || env::var_os("RUST_BOOTSTRAP_CONFIG").is_some() {
|
||||
"profile = \"user\"".to_owned()
|
||||
} else {
|
||||
assert!(file.ends_with("config.dist.toml"));
|
||||
std::fs::read_to_string(file).unwrap()
|
||||
};
|
||||
let contents = if file.ends_with("bootstrap.toml")
|
||||
|| file.ends_with("config.toml")
|
||||
|| env::var_os("RUST_BOOTSTRAP_CONFIG").is_some()
|
||||
{
|
||||
"profile = \"user\"".to_owned()
|
||||
} else {
|
||||
assert!(file.ends_with("config.dist.toml") || file.ends_with("bootstrap.dist.toml"));
|
||||
std::fs::read_to_string(file).unwrap()
|
||||
};
|
||||
|
||||
toml::from_str(&contents).and_then(|table: toml::Value| TomlConfig::deserialize(table))
|
||||
}
|
||||
|
|
@ -402,7 +404,7 @@ fn jobs_precedence() {
|
|||
);
|
||||
assert_eq!(config.jobs, Some(67890));
|
||||
|
||||
// `--set build.jobs` should take precedence over `config.toml`.
|
||||
// `--set build.jobs` should take precedence over `bootstrap.toml`.
|
||||
let config = Config::parse_inner(
|
||||
Flags::parse(&[
|
||||
"check".to_owned(),
|
||||
|
|
@ -420,7 +422,7 @@ fn jobs_precedence() {
|
|||
);
|
||||
assert_eq!(config.jobs, Some(12345));
|
||||
|
||||
// `--jobs` > `--set build.jobs` > `config.toml`
|
||||
// `--jobs` > `--set build.jobs` > `bootstrap.toml`
|
||||
let config = Config::parse_inner(
|
||||
Flags::parse(&[
|
||||
"check".to_owned(),
|
||||
|
|
|
|||
|
|
@ -124,7 +124,7 @@ impl Config {
|
|||
if let Ok(in_nix_shell) = in_nix_shell {
|
||||
eprintln!(
|
||||
"The IN_NIX_SHELL environment variable is `{in_nix_shell}`; \
|
||||
you may need to set `patch-binaries-for-nix=true` in config.toml"
|
||||
you may need to set `patch-binaries-for-nix=true` in bootstrap.toml"
|
||||
);
|
||||
}
|
||||
}
|
||||
|
|
@ -699,7 +699,7 @@ impl Config {
|
|||
help_on_error = "ERROR: failed to download pre-built rustc from CI
|
||||
|
||||
NOTE: old builds get deleted after a certain time
|
||||
HELP: if trying to compile an old commit of rustc, disable `download-rustc` in config.toml:
|
||||
HELP: if trying to compile an old commit of rustc, disable `download-rustc` in bootstrap.toml:
|
||||
|
||||
[rust]
|
||||
download-rustc = false
|
||||
|
|
@ -783,7 +783,7 @@ download-rustc = false
|
|||
println!("HELP: Consider rebasing to a newer commit if available.");
|
||||
}
|
||||
Err(e) => {
|
||||
eprintln!("ERROR: Failed to parse CI LLVM config.toml: {e}");
|
||||
eprintln!("ERROR: Failed to parse CI LLVM bootstrap.toml: {e}");
|
||||
exit!(2);
|
||||
}
|
||||
};
|
||||
|
|
@ -816,7 +816,7 @@ download-rustc = false
|
|||
HELP: There could be two reasons behind this:
|
||||
1) The host triple is not supported for `download-ci-llvm`.
|
||||
2) Old builds get deleted after a certain time.
|
||||
HELP: In either case, disable `download-ci-llvm` in your config.toml:
|
||||
HELP: In either case, disable `download-ci-llvm` in your bootstrap.toml:
|
||||
|
||||
[llvm]
|
||||
download-ci-llvm = false
|
||||
|
|
@ -845,7 +845,7 @@ download-rustc = false
|
|||
HELP: There could be two reasons behind this:
|
||||
1) The host triple is not supported for `download-ci-gcc`.
|
||||
2) Old builds get deleted after a certain time.
|
||||
HELP: In either case, disable `download-ci-gcc` in your config.toml:
|
||||
HELP: In either case, disable `download-ci-gcc` in your bootstrap.toml:
|
||||
|
||||
[gcc]
|
||||
download-ci-gcc = false
|
||||
|
|
|
|||
|
|
@ -153,7 +153,7 @@ pub fn check(build: &mut Build) {
|
|||
Couldn't find required command: cmake
|
||||
|
||||
You should install cmake, or set `download-ci-llvm = true` in the
|
||||
`[llvm]` section of `config.toml` to download LLVM rather
|
||||
`[llvm]` section of `bootstrap.toml` to download LLVM rather
|
||||
than building it.
|
||||
"
|
||||
);
|
||||
|
|
@ -339,7 +339,7 @@ than building it.
|
|||
None => panic!(
|
||||
"when targeting MUSL either the rust.musl-root \
|
||||
option or the target.$TARGET.musl-root option must \
|
||||
be specified in config.toml"
|
||||
be specified in bootstrap.toml"
|
||||
),
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ pub enum GitRepo {
|
|||
/// organize).
|
||||
#[derive(Clone)]
|
||||
pub struct Build {
|
||||
/// User-specified configuration from `config.toml`.
|
||||
/// User-specified configuration from `bootstrap.toml`.
|
||||
config: Config,
|
||||
|
||||
// Version information
|
||||
|
|
@ -538,7 +538,7 @@ impl Build {
|
|||
/// This avoids contributors checking in a submodule change by accident.
|
||||
fn update_existing_submodules(&self) {
|
||||
// Avoid running git when there isn't a git checkout, or the user has
|
||||
// explicitly disabled submodules in `config.toml`.
|
||||
// explicitly disabled submodules in `bootstrap.toml`.
|
||||
if !self.config.submodules() {
|
||||
return;
|
||||
}
|
||||
|
|
@ -671,7 +671,7 @@ impl Build {
|
|||
}
|
||||
|
||||
/// Gets the space-separated set of activated features for the standard library.
|
||||
/// This can be configured with the `std-features` key in config.toml.
|
||||
/// This can be configured with the `std-features` key in bootstrap.toml.
|
||||
fn std_features(&self, target: TargetSelection) -> String {
|
||||
let mut features: BTreeSet<&str> =
|
||||
self.config.rust_std_features.iter().map(|s| s.as_str()).collect();
|
||||
|
|
@ -1925,7 +1925,7 @@ Couldn't find required command: ninja (or ninja-build)
|
|||
|
||||
You should install ninja as described at
|
||||
<https://github.com/ninja-build/ninja/wiki/Pre-built-Ninja-packages>,
|
||||
or set `ninja = false` in the `[llvm]` section of `config.toml`.
|
||||
or set `ninja = false` in the `[llvm]` section of `bootstrap.toml`.
|
||||
Alternatively, set `download-ci-llvm = true` in that `[llvm]` section
|
||||
to download LLVM rather than building it.
|
||||
"
|
||||
|
|
|
|||
|
|
@ -4,8 +4,8 @@
|
|||
//! C and C++ compilers for each target configured. A compiler is found through
|
||||
//! a number of vectors (in order of precedence)
|
||||
//!
|
||||
//! 1. Configuration via `target.$target.cc` in `config.toml`.
|
||||
//! 2. Configuration via `target.$target.android-ndk` in `config.toml`, if
|
||||
//! 1. Configuration via `target.$target.cc` in `bootstrap.toml`.
|
||||
//! 2. Configuration via `target.$target.android-ndk` in `bootstrap.toml`, if
|
||||
//! applicable
|
||||
//! 3. Special logic to probe on OpenBSD
|
||||
//! 4. The `CC_$target` environment variable.
|
||||
|
|
@ -122,7 +122,7 @@ pub fn find(build: &Build) {
|
|||
|
||||
/// Probes and configures the C and C++ compilers for a single target.
|
||||
///
|
||||
/// This function uses both user-specified configuration (from `config.toml`) and auto-detection
|
||||
/// This function uses both user-specified configuration (from `bootstrap.toml`) and auto-detection
|
||||
/// logic to determine the correct C/C++ compilers for the target. It also determines the appropriate
|
||||
/// archiver (`ar`) and sets up additional compilation flags (both handled and unhandled).
|
||||
pub fn find_target(build: &Build, target: TargetSelection) {
|
||||
|
|
@ -186,7 +186,7 @@ pub fn find_target(build: &Build, target: TargetSelection) {
|
|||
}
|
||||
|
||||
/// Determines the default compiler for a given target and language when not explicitly
|
||||
/// configured in `config.toml`.
|
||||
/// configured in `bootstrap.toml`.
|
||||
fn default_compiler(
|
||||
cfg: &mut cc::Build,
|
||||
compiler: Language,
|
||||
|
|
@ -195,7 +195,7 @@ fn default_compiler(
|
|||
) -> Option<PathBuf> {
|
||||
match &*target.triple {
|
||||
// When compiling for android we may have the NDK configured in the
|
||||
// config.toml in which case we look there. Otherwise the default
|
||||
// bootstrap.toml in which case we look there. Otherwise the default
|
||||
// compiler already takes into account the triple in question.
|
||||
t if t.contains("android") => {
|
||||
build.config.android_ndk.as_ref().map(|ndk| ndk_compiler(compiler, &target.triple, ndk))
|
||||
|
|
|
|||
|
|
@ -385,4 +385,9 @@ pub const CONFIG_CHANGE_HISTORY: &[ChangeInfo] = &[
|
|||
severity: ChangeSeverity::Info,
|
||||
summary: "Added new option `build.exclude` which works the same way as `--exclude` flag on `x`.",
|
||||
},
|
||||
ChangeInfo {
|
||||
change_id: 137081,
|
||||
severity: ChangeSeverity::Warning,
|
||||
summary: "The default configuration filename has changed from `config.toml` to `bootstrap.toml`. `config.toml` is deprecated but remains supported for backward compatibility.",
|
||||
},
|
||||
];
|
||||
|
|
|
|||
|
|
@ -229,8 +229,8 @@ trap datecheck EXIT
|
|||
# sccache server at the start of the build, but no need to worry if this fails.
|
||||
SCCACHE_IDLE_TIMEOUT=10800 sccache --start-server || true
|
||||
|
||||
# Our build may overwrite config.toml, so we remove it here
|
||||
rm -f config.toml
|
||||
# Our build may overwrite bootstrap.toml, so we remove it here
|
||||
rm -f bootstrap.toml
|
||||
|
||||
$SRC/configure $RUST_CONFIGURE_ARGS
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ which means that LLVM assertion failures can show up as compiler crashes (not
|
|||
ICEs but "real" crashes) and other sorts of weird behavior. If you are
|
||||
encountering these, it is a good idea to try using a compiler with LLVM
|
||||
assertions enabled - either an "alt" nightly or a compiler you build yourself
|
||||
by setting `[llvm] assertions=true` in your config.toml - and see whether
|
||||
by setting `[llvm] assertions=true` in your bootstrap.toml - and see whether
|
||||
anything turns up.
|
||||
|
||||
The rustc build process builds the LLVM tools into
|
||||
|
|
@ -160,7 +160,7 @@ from `./build/<host-triple>/llvm/bin/` with the LLVM IR emitted by rustc.
|
|||
When investigating the implementation of LLVM itself, you should be
|
||||
aware of its [internal debug infrastructure][llvm-debug].
|
||||
This is provided in LLVM Debug builds, which you enable for rustc
|
||||
LLVM builds by changing this setting in the config.toml:
|
||||
LLVM builds by changing this setting in the bootstrap.toml:
|
||||
```
|
||||
[llvm]
|
||||
# Indicates whether the LLVM assertions are enabled or not
|
||||
|
|
|
|||
|
|
@ -144,7 +144,7 @@ so let's go through each in detail.
|
|||
Note that `profile = "compiler"` and other defaults set by `./x setup`
|
||||
download LLVM from CI instead of building it from source.
|
||||
You should disable this temporarily to make sure your changes are being used.
|
||||
This is done by having the following setting in `config.toml`:
|
||||
This is done by having the following setting in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[llvm]
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ like the standard library (std) or the compiler (rustc).
|
|||
- Document internal rustc items
|
||||
|
||||
Compiler documentation is not built by default.
|
||||
To create it by default with `x doc`, modify `config.toml`:
|
||||
To create it by default with `x doc`, modify `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -159,15 +159,15 @@ similar to the one declared in section [What is `x.py`](#what-is-xpy), but
|
|||
it works as an independent process to execute the `x.py` rather than calling the
|
||||
shell to run the platform related scripts.
|
||||
|
||||
## Create a `config.toml`
|
||||
## Create a `bootstrap.toml`
|
||||
|
||||
To start, run `./x setup` and select the `compiler` defaults. This will do some initialization
|
||||
and create a `config.toml` for you with reasonable defaults. If you use a different default (which
|
||||
and create a `bootstrap.toml` for you with reasonable defaults. If you use a different default (which
|
||||
you'll likely want to do if you want to contribute to an area of rust other than the compiler, such
|
||||
as rustdoc), make sure to read information about that default (located in `src/bootstrap/defaults`)
|
||||
as the build process may be different for other defaults.
|
||||
|
||||
Alternatively, you can write `config.toml` by hand. See `config.example.toml` for all the available
|
||||
Alternatively, you can write `bootstrap.toml` by hand. See `bootstrap.example.toml` for all the available
|
||||
settings and explanations of them. See `src/bootstrap/defaults` for common settings to change.
|
||||
|
||||
If you have already built `rustc` and you change settings related to LLVM, then you may have to
|
||||
|
|
@ -206,7 +206,7 @@ See the chapters on
|
|||
Note that building will require a relatively large amount of storage space.
|
||||
You may want to have upwards of 10 or 15 gigabytes available to build the compiler.
|
||||
|
||||
Once you've created a `config.toml`, you are now ready to run
|
||||
Once you've created a `bootstrap.toml`, you are now ready to run
|
||||
`x`. There are a lot of options here, but let's start with what is
|
||||
probably the best "go to" command for building a local compiler:
|
||||
|
||||
|
|
@ -326,7 +326,7 @@ involve proc macros or build scripts, you must be sure to explicitly build targe
|
|||
host platform (in this case, `x86_64-unknown-linux-gnu`).
|
||||
|
||||
If you want to always build for other targets without needing to pass flags to `x build`,
|
||||
you can configure this in the `[build]` section of your `config.toml` like so:
|
||||
you can configure this in the `[build]` section of your `bootstrap.toml` like so:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
@ -336,8 +336,8 @@ target = ["x86_64-unknown-linux-gnu", "wasm32-wasip1"]
|
|||
Note that building for some targets requires having external dependencies installed
|
||||
(e.g. building musl targets requires a local copy of musl).
|
||||
Any target-specific configuration (e.g. the path to a local copy of musl)
|
||||
will need to be provided by your `config.toml`.
|
||||
Please see `config.example.toml` for information on target-specific configuration keys.
|
||||
will need to be provided by your `bootstrap.toml`.
|
||||
Please see `bootstrap.example.toml` for information on target-specific configuration keys.
|
||||
|
||||
For examples of the complete configuration necessary to build a target, please visit
|
||||
[the rustc book](https://doc.rust-lang.org/rustc/platform-support.html),
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ able to configure Rust to treat your build as the system LLVM to avoid
|
|||
redundant builds.
|
||||
|
||||
You can tell Rust to use a pre-built version of LLVM using the `target` section
|
||||
of `config.toml`:
|
||||
of `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[target.x86_64-unknown-linux-gnu]
|
||||
|
|
@ -55,8 +55,8 @@ for codegen tests. This tool is normally built with LLVM, but if you use your
|
|||
own preinstalled LLVM, you will need to provide `FileCheck` in some other way.
|
||||
On Debian-based systems, you can install the `llvm-N-tools` package (where `N`
|
||||
is the LLVM version number, e.g. `llvm-8-tools`). Alternately, you can specify
|
||||
the path to `FileCheck` with the `llvm-filecheck` config item in `config.toml`
|
||||
or you can disable codegen test with the `codegen-tests` item in `config.toml`.
|
||||
the path to `FileCheck` with the `llvm-filecheck` config item in `bootstrap.toml`
|
||||
or you can disable codegen test with the `codegen-tests` item in `bootstrap.toml`.
|
||||
|
||||
## Creating a target specification
|
||||
|
||||
|
|
@ -141,14 +141,14 @@ After this, run `cargo update -p libc` to update the lockfiles.
|
|||
|
||||
Beware that if you patch to a local `path` dependency, this will enable
|
||||
warnings for that dependency. Some dependencies are not warning-free, and due
|
||||
to the `deny-warnings` setting in `config.toml`, the build may suddenly start
|
||||
to the `deny-warnings` setting in `bootstrap.toml`, the build may suddenly start
|
||||
to fail.
|
||||
To work around warnings, you may want to:
|
||||
- Modify the dependency to remove the warnings
|
||||
- Or for local development purposes, suppress the warnings by setting deny-warnings = false in config.toml.
|
||||
- Or for local development purposes, suppress the warnings by setting deny-warnings = false in bootstrap.toml.
|
||||
|
||||
```toml
|
||||
# config.toml
|
||||
# bootstrap.toml
|
||||
[rust]
|
||||
deny-warnings = false
|
||||
```
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ This page describes how you can use these approaches when building `rustc` yours
|
|||
|
||||
Link-time optimization is a powerful compiler technique that can increase program performance. To
|
||||
enable (Thin-)LTO when building `rustc`, set the `rust.lto` config option to `"thin"`
|
||||
in `config.toml`:
|
||||
in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[rust]
|
||||
|
|
@ -34,7 +34,7 @@ Enabling LTO on Linux has [produced] speed-ups by up to 10%.
|
|||
|
||||
Using a different memory allocator for `rustc` can provide significant performance benefits. If you
|
||||
want to enable the `jemalloc` allocator, you can set the `rust.jemalloc` option to `true`
|
||||
in `config.toml`:
|
||||
in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[rust]
|
||||
|
|
@ -46,7 +46,7 @@ jemalloc = true
|
|||
## Codegen units
|
||||
|
||||
Reducing the amount of codegen units per `rustc` crate can produce a faster build of the compiler.
|
||||
You can modify the number of codegen units for `rustc` and `libstd` in `config.toml` with the
|
||||
You can modify the number of codegen units for `rustc` and `libstd` in `bootstrap.toml` with the
|
||||
following options:
|
||||
|
||||
```toml
|
||||
|
|
@ -67,7 +67,7 @@ RUSTFLAGS="-C target_cpu=x86-64-v3" ./x build ...
|
|||
```
|
||||
|
||||
If you also want to compile LLVM for a specific instruction set, you can set `llvm` flags
|
||||
in `config.toml`:
|
||||
in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[llvm]
|
||||
|
|
|
|||
|
|
@ -305,7 +305,7 @@ subsequent rebuilds:
|
|||
```
|
||||
|
||||
If you don't want to include the flag with every command, you can enable it in
|
||||
the `config.toml`:
|
||||
the `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[rust]
|
||||
|
|
@ -384,20 +384,20 @@ ln -s ./src/tools/nix-dev-shell/envrc-shell ./.envrc # Use nix-shell
|
|||
### Note
|
||||
|
||||
Note that when using nix on a not-NixOS distribution, it may be necessary to set
|
||||
**`patch-binaries-for-nix = true` in `config.toml`**. Bootstrap tries to detect
|
||||
**`patch-binaries-for-nix = true` in `bootstrap.toml`**. Bootstrap tries to detect
|
||||
whether it's running in nix and enable patching automatically, but this
|
||||
detection can have false negatives.
|
||||
|
||||
You can also use your nix shell to manage `config.toml`:
|
||||
You can also use your nix shell to manage `bootstrap.toml`:
|
||||
|
||||
```nix
|
||||
let
|
||||
config = pkgs.writeText "rustc-config" ''
|
||||
# Your config.toml content goes here
|
||||
# Your bootstrap.toml content goes here
|
||||
''
|
||||
pkgs.mkShell {
|
||||
/* ... */
|
||||
# This environment variable tells bootstrap where our config.toml is.
|
||||
# This environment variable tells bootstrap where our bootstrap.toml is.
|
||||
RUST_BOOTSTRAP_CONFIG = config;
|
||||
}
|
||||
```
|
||||
|
|
|
|||
|
|
@ -11,13 +11,13 @@ chapter](./backend/debugging.md)).
|
|||
## Configuring the compiler
|
||||
|
||||
By default, rustc is built without most debug information. To enable debug info,
|
||||
set `debug = true` in your config.toml.
|
||||
set `debug = true` in your bootstrap.toml.
|
||||
|
||||
Setting `debug = true` turns on many different debug options (e.g., `debug-assertions`,
|
||||
`debug-logging`, etc.) which can be individually tweaked if you want to, but many people
|
||||
simply set `debug = true`.
|
||||
|
||||
If you want to use GDB to debug rustc, please set `config.toml` with options:
|
||||
If you want to use GDB to debug rustc, please set `bootstrap.toml` with options:
|
||||
|
||||
```toml
|
||||
[rust]
|
||||
|
|
@ -35,14 +35,14 @@ debuginfo-level = 2
|
|||
|
||||
The default configuration will enable `symbol-mangling-version` v0.
|
||||
This requires at least GDB v10.2,
|
||||
otherwise you need to disable new symbol-mangling-version in `config.toml`.
|
||||
otherwise you need to disable new symbol-mangling-version in `bootstrap.toml`.
|
||||
|
||||
```toml
|
||||
[rust]
|
||||
new-symbol-mangling = false
|
||||
```
|
||||
|
||||
> See the comments in `config.example.toml` for more info.
|
||||
> See the comments in `bootstrap.example.toml` for more info.
|
||||
|
||||
You will need to rebuild the compiler after changing any configuration option.
|
||||
|
||||
|
|
@ -373,7 +373,7 @@ error: aborting due to previous error
|
|||
|
||||
## Configuring CodeLLDB for debugging `rustc`
|
||||
|
||||
If you are using VSCode, and have edited your `config.toml` to request debugging
|
||||
If you are using VSCode, and have edited your `bootstrap.toml` to request debugging
|
||||
level 1 or 2 for the parts of the code you're interested in, then you should be
|
||||
able to use the [CodeLLDB] extension in VSCode to debug it.
|
||||
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@ what actually results in superior throughput.
|
|||
You may want to build rustc from source with debug assertions to find
|
||||
additional bugs, though this is a trade-off: it can slow down fuzzing by
|
||||
requiring extra work for every execution. To enable debug assertions, add this
|
||||
to `config.toml` when compiling rustc:
|
||||
to `bootstrap.toml` when compiling rustc:
|
||||
|
||||
```toml
|
||||
[rust]
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Detailed instructions and examples are documented in the
|
|||
[coverage map]: https://llvm.org/docs/CoverageMappingFormat.html
|
||||
[rustc-book-instrument-coverage]: https://doc.rust-lang.org/nightly/rustc/instrument-coverage.html
|
||||
|
||||
## Recommended `config.toml` settings
|
||||
## Recommended `bootstrap.toml` settings
|
||||
|
||||
When working on the coverage instrumentation code, it is usually necessary to
|
||||
**enable the profiler runtime** by setting `profiler = true` in `[build]`.
|
||||
|
|
@ -83,7 +83,7 @@ statically links coverage-instrumented binaries with LLVM runtime code
|
|||
In the `rustc` source tree,
|
||||
`library/profiler_builtins` bundles the LLVM `compiler-rt` code into a Rust library crate.
|
||||
Note that when building `rustc`,
|
||||
`profiler_builtins` is only included when `build.profiler = true` is set in `config.toml`.
|
||||
`profiler_builtins` is only included when `build.profiler = true` is set in `bootstrap.toml`.
|
||||
|
||||
When compiling with `-C instrument-coverage`,
|
||||
[`CrateLoader::postprocess()`][crate-loader-postprocess] dynamically loads
|
||||
|
|
@ -115,7 +115,7 @@ human-readable coverage report.
|
|||
|
||||
> Tests in `coverage-run` mode have an implicit `//@ needs-profiler-runtime`
|
||||
> directive, so they will be skipped if the profiler runtime has not been
|
||||
> [enabled in `config.toml`](#recommended-configtoml-settings).
|
||||
> [enabled in `bootstrap.toml`](#recommended-configtoml-settings).
|
||||
|
||||
Finally, the [`tests/codegen/instrument-coverage/testprog.rs`] test compiles a simple Rust program
|
||||
with `-C instrument-coverage` and compares the compiled program's LLVM IR to
|
||||
|
|
|
|||
|
|
@ -351,7 +351,7 @@ approach is to turn [`RefCell`]s into [`Mutex`]s -- that is, we
|
|||
switch to thread-safe internal mutability. However, there are ongoing
|
||||
challenges with lock contention, maintaining query-system invariants under
|
||||
concurrency, and the complexity of the code base. One can try out the current
|
||||
work by enabling parallel compilation in `config.toml`. It's still early days,
|
||||
work by enabling parallel compilation in `bootstrap.toml`. It's still early days,
|
||||
but there are already some promising performance improvements.
|
||||
|
||||
[`RefCell`]: https://doc.rust-lang.org/std/cell/struct.RefCell.html
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ The `rustc` version of this can be found in `library/profiler_builtins` which
|
|||
basically packs the C code from `compiler-rt` into a Rust crate.
|
||||
|
||||
In order for `profiler_builtins` to be built, `profiler = true` must be set
|
||||
in `rustc`'s `config.toml`.
|
||||
in `rustc`'s `bootstrap.toml`.
|
||||
|
||||
[compiler-rt-profile]: https://github.com/llvm/llvm-project/tree/main/compiler-rt/lib/profile
|
||||
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ Example output for the compiler:
|
|||
|
||||
Since this doesn't seem to work with incremental compilation or `./x check`,
|
||||
you will be compiling rustc _a lot_.
|
||||
I recommend changing a few settings in `config.toml` to make it bearable:
|
||||
I recommend changing a few settings in `bootstrap.toml` to make it bearable:
|
||||
```
|
||||
[rust]
|
||||
# A debug build takes _a third_ as long on my machine,
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or
|
|||
|
||||
- Get a clean checkout of rust-lang/master, or whatever it is you want
|
||||
to profile.
|
||||
- Set the following settings in your `config.toml`:
|
||||
- Set the following settings in your `bootstrap.toml`:
|
||||
- `debuginfo-level = 1` - enables line debuginfo
|
||||
- `jemalloc = false` - lets you do memory use profiling with valgrind
|
||||
- leave everything else the defaults
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ which will download and build the suite for you, build a local compiler toolchai
|
|||
|
||||
You can use the `./x perf <command> [options]` command to use this integration.
|
||||
|
||||
You can use normal bootstrap flags for this command, such as `--stage 1` or `--stage 2`, for example to modify the stage of the created sysroot. It might also be useful to configure `config.toml` to better support profiling, e.g. set `rust.debuginfo-level = 1` to add source line information to the built compiler.
|
||||
You can use normal bootstrap flags for this command, such as `--stage 1` or `--stage 2`, for example to modify the stage of the created sysroot. It might also be useful to configure `bootstrap.toml` to better support profiling, e.g. set `rust.debuginfo-level = 1` to add source line information to the built compiler.
|
||||
|
||||
`x perf` currently supports the following commands:
|
||||
- `benchmark <id>`: Benchmark the compiler and store the results under the passed `id`.
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ compiler we're using to build rustc will aid our analysis greatly by allowing WP
|
|||
symbols correctly. Unfortunately, the stage 0 compiler does not have symbols turned on which is why
|
||||
we'll need to build a stage 1 compiler and then a stage 2 compiler ourselves.
|
||||
|
||||
To do this, make sure you have set `debuginfo-level = 1` in your `config.toml` file. This tells
|
||||
To do this, make sure you have set `debuginfo-level = 1` in your `bootstrap.toml` file. This tells
|
||||
rustc to generate debug information which includes stack frames when bootstrapping.
|
||||
|
||||
Now you can build the stage 1 compiler: `x build --stage 1 -i library` or however
|
||||
|
|
|
|||
|
|
@ -58,12 +58,12 @@ does is call the `main()` that's in this crate's `lib.rs`, though.)
|
|||
* If you want to copy those docs to a webserver, copy all of
|
||||
`build/host/doc`, since that's where the CSS, JS, fonts, and landing
|
||||
page are.
|
||||
* For frontend debugging, disable the `rust.docs-minification` option in [`config.toml`].
|
||||
* For frontend debugging, disable the `rust.docs-minification` option in [`bootstrap.toml`].
|
||||
* Use `./x test tests/rustdoc*` to run the tests using a stage1
|
||||
rustdoc.
|
||||
* See [Rustdoc internals] for more information about tests.
|
||||
|
||||
[`config.toml`]: ./building/how-to-build-and-run.md
|
||||
[`bootstrap.toml`]: ./building/how-to-build-and-run.md
|
||||
|
||||
## Code structure
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ implementation:
|
|||
|
||||
* The sanitizer runtime libraries are part of the [compiler-rt] project, and
|
||||
[will be built][sanitizer-build] on [supported targets][sanitizer-targets]
|
||||
when enabled in `config.toml`:
|
||||
when enabled in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
@ -80,7 +80,7 @@ Sanitizers are validated by code generation tests in
|
|||
[`tests/ui/sanitizer/`][test-ui] directory.
|
||||
|
||||
Testing sanitizer functionality requires the sanitizer runtimes (built when
|
||||
`sanitizer = true` in `config.toml`) and target providing support for particular
|
||||
`sanitizer = true` in `bootstrap.toml`) and target providing support for particular
|
||||
sanitizer. When sanitizer is unsupported on given target, sanitizers tests will
|
||||
be ignored. This behaviour is controlled by compiletest `needs-sanitizer-*`
|
||||
directives.
|
||||
|
|
|
|||
|
|
@ -435,7 +435,7 @@ To learn more about the dashboard, see the [Datadog CI docs].
|
|||
|
||||
## Determining the CI configuration
|
||||
|
||||
If you want to determine which `config.toml` settings are used in CI for a
|
||||
If you want to determine which `bootstrap.toml` settings are used in CI for a
|
||||
particular job, it is probably easiest to just look at the build log. To do
|
||||
this:
|
||||
|
||||
|
|
|
|||
|
|
@ -525,10 +525,10 @@ data into a human-readable code coverage report.
|
|||
|
||||
Instrumented binaries need to be linked against the LLVM profiler runtime, so
|
||||
`coverage-run` tests are **automatically skipped** unless the profiler runtime
|
||||
is enabled in `config.toml`:
|
||||
is enabled in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
# config.toml
|
||||
# bootstrap.toml
|
||||
[build]
|
||||
profiler = true
|
||||
```
|
||||
|
|
|
|||
|
|
@ -160,9 +160,9 @@ settings:
|
|||
stable support for `asm!`
|
||||
- `needs-profiler-runtime` — ignores the test if the profiler runtime was not
|
||||
enabled for the target
|
||||
(`build.profiler = true` in rustc's `config.toml`)
|
||||
(`build.profiler = true` in rustc's `bootstrap.toml`)
|
||||
- `needs-sanitizer-support` — ignores if the sanitizer support was not enabled
|
||||
for the target (`sanitizers = true` in rustc's `config.toml`)
|
||||
for the target (`sanitizers = true` in rustc's `bootstrap.toml`)
|
||||
- `needs-sanitizer-{address,hwaddress,leak,memory,thread}` — ignores if the
|
||||
corresponding sanitizer is not enabled for the target (AddressSanitizer,
|
||||
hardware-assisted AddressSanitizer, LeakSanitizer, MemorySanitizer or
|
||||
|
|
@ -172,7 +172,7 @@ settings:
|
|||
flag, or running on fuchsia.
|
||||
- `needs-unwind` — ignores if the target does not support unwinding
|
||||
- `needs-rust-lld` — ignores if the rust lld support is not enabled (`rust.lld =
|
||||
true` in `config.toml`)
|
||||
true` in `bootstrap.toml`)
|
||||
- `needs-threads` — ignores if the target does not have threading support
|
||||
- `needs-subprocess` — ignores if the target does not have subprocess support
|
||||
- `needs-symlink` — ignores if the target does not support symlinks. This can be
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ The [`src/ci/docker/run.sh`] script is used to build a specific Docker image, ru
|
|||
build Rust within the image, and either run tests or prepare a set of archives designed for distribution. The script will mount your local Rust source tree in read-only mode, and an `obj` directory in read-write mode. All the compiler artifacts will be stored in the `obj` directory. The shell will start out in the `obj`directory. From there, it will execute `../src/ci/run.sh` which starts the build as defined by the Docker image.
|
||||
|
||||
You can run `src/ci/docker/run.sh <image-name>` directly. A few important notes regarding the `run.sh` script:
|
||||
- When executed on CI, the script expects that all submodules are checked out. If some submodule that is accessed by the job is not available, the build will result in an error. You should thus make sure that you have all required submodules checked out locally. You can either do that manually through git, or set `submodules = true` in your `config.toml` and run a command such as `x build` to let bootstrap download the most important submodules (this might not be enough for the given CI job that you are trying to execute though).
|
||||
- When executed on CI, the script expects that all submodules are checked out. If some submodule that is accessed by the job is not available, the build will result in an error. You should thus make sure that you have all required submodules checked out locally. You can either do that manually through git, or set `submodules = true` in your `bootstrap.toml` and run a command such as `x build` to let bootstrap download the most important submodules (this might not be enough for the given CI job that you are trying to execute though).
|
||||
- `<image-name>` corresponds to a single directory located in one of the `src/ci/docker/host-*` directories. Note that image name does not necessarily correspond to a job name, as some jobs execute the same image, but with different environment variables or Docker build arguments (this is a part of the complexity that makes it difficult to run CI jobs locally).
|
||||
- If you are executing a "dist" job (job beginning with `dist-`), you should set the `DEPLOY=1` environment variable.
|
||||
- If you are executing an "alternative dist" job (job beginning with `dist-` and ending with `-alt`), you should set the `DEPLOY_ALT=1` environment variable.
|
||||
|
|
|
|||
|
|
@ -189,7 +189,7 @@ just like when running the tests without the `--bless` flag.
|
|||
|
||||
There are a few options for running tests:
|
||||
|
||||
* `config.toml` has the `rust.verbose-tests` option. If `false`, each test will
|
||||
* `bootstrap.toml` has the `rust.verbose-tests` option. If `false`, each test will
|
||||
print a single dot (the default). If `true`, the name of every test will be
|
||||
printed. This is equivalent to the `--quiet` option in the [Rust test
|
||||
harness](https://doc.rust-lang.org/rustc/tests/).
|
||||
|
|
@ -353,7 +353,7 @@ coordinate running tests (see [src/bootstrap/src/core/build_steps/test.rs]).
|
|||
First thing to know is that it only supports linux x86_64 at the moment. We will
|
||||
extend its support later on.
|
||||
|
||||
You need to update `codegen-backends` value in your `config.toml` file in the
|
||||
You need to update `codegen-backends` value in your `bootstrap.toml` file in the
|
||||
`[rust]` section and add "gcc" in the array:
|
||||
|
||||
```toml
|
||||
|
|
|
|||
|
|
@ -185,11 +185,11 @@ rustc.
|
|||
|
||||
While calls to `error!`, `warn!` and `info!` are included in every build of the compiler,
|
||||
calls to `debug!` and `trace!` are only included in the program if
|
||||
`debug-logging=true` is turned on in config.toml (it is
|
||||
`debug-logging=true` is turned on in bootstrap.toml (it is
|
||||
turned off by default), so if you don't see `DEBUG` logs, especially
|
||||
if you run the compiler with `RUSTC_LOG=rustc rustc some.rs` and only see
|
||||
`INFO` logs, make sure that `debug-logging=true` is turned on in your
|
||||
config.toml.
|
||||
bootstrap.toml.
|
||||
|
||||
## Logging etiquette and conventions
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Rust's source-based code coverage requires the Rust "profiler runtime". Without
|
|||
|
||||
The Rust `nightly` distribution channel includes the profiler runtime, by default.
|
||||
|
||||
> **Important**: If you are building the Rust compiler from the source distribution, the profiler runtime is _not_ enabled in the default `config.example.toml`. Edit your `config.toml` file and ensure the `profiler` feature is set it to `true` (either under the `[build]` section, or under the settings for an individual `[target.<triple>]`):
|
||||
> **Important**: If you are building the Rust compiler from the source distribution, the profiler runtime is _not_ enabled in the default `bootstrap.example.toml`. Edit your `bootstrap.toml` file and ensure the `profiler` feature is set it to `true` (either under the `[build]` section, or under the settings for an individual `[target.<triple>]`):
|
||||
>
|
||||
> ```toml
|
||||
> # Build the profiler runtime (required when compiling with options that depend
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ What format do binaries use by default? ELF, PE, something else?
|
|||
## Building the target
|
||||
|
||||
If Rust doesn't build the target by default, how can users build it? Can users
|
||||
just add it to the `target` list in `config.toml`?
|
||||
just add it to the `target` list in `bootstrap.toml`?
|
||||
|
||||
## Building Rust programs
|
||||
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ exec /path/to/ohos-sdk/linux/native/llvm/bin/clang++ \
|
|||
|
||||
## Building the target
|
||||
|
||||
To build a rust toolchain, create a `config.toml` with the following contents:
|
||||
To build a rust toolchain, create a `bootstrap.toml` with the following contents:
|
||||
|
||||
```toml
|
||||
profile = "compiler"
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ $ rustup target add x86_64-apple-ios
|
|||
```
|
||||
|
||||
The tier 3 targets can be built by enabling them for a `rustc` build in
|
||||
`config.toml`, by adding, for example:
|
||||
`bootstrap.toml`, by adding, for example:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ The following APIs are currently known to have missing or incomplete support:
|
|||
## Building the target
|
||||
|
||||
The targets can be built by enabling them for a `rustc` build in
|
||||
`config.toml`, by adding, for example:
|
||||
`bootstrap.toml`, by adding, for example:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ case `XROS_DEPLOYMENT_TARGET`.
|
|||
## Building the target
|
||||
|
||||
The targets can be built by enabling them for a `rustc` build in
|
||||
`config.toml`, by adding, for example:
|
||||
`bootstrap.toml`, by adding, for example:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ case `WATCHOS_DEPLOYMENT_TARGET`.
|
|||
## Building the target
|
||||
|
||||
The targets can be built by enabling them for a `rustc` build in
|
||||
`config.toml`, by adding, for example:
|
||||
`bootstrap.toml`, by adding, for example:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ See the docs on [`*-apple-darwin`](apple-darwin.md) for general macOS requiremen
|
|||
|
||||
## Building the target
|
||||
|
||||
You can build Rust with support for the targets by adding it to the `target` list in `config.toml`:
|
||||
You can build Rust with support for the targets by adding it to the `target` list in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ See the docs on [`*-apple-ios`](apple-ios.md) for general iOS requirements.
|
|||
|
||||
## Building the target
|
||||
|
||||
You can build Rust with support for the targets by adding it to the `target` list in `config.toml`:
|
||||
You can build Rust with support for the targets by adding it to the `target` list in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ To build this target Xcode 12 or higher on macOS is required.
|
|||
|
||||
## Building the target
|
||||
|
||||
You can build Rust with support for the targets by adding it to the `target` list in `config.toml`:
|
||||
You can build Rust with support for the targets by adding it to the `target` list in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ To put this in practice:
|
|||
## Building the target
|
||||
|
||||
You can build Rust with support for the targets by adding it to the `target`
|
||||
list in `config.toml`:
|
||||
list in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ The target definition can be seen [here](https://github.com/rust-lang/rust/blob/
|
|||
## Building the target
|
||||
Because it is Tier 3, rust does not yet ship pre-compiled artifacts for this target.
|
||||
|
||||
Therefore, you can build Rust with support for the target by adding it to the target list in config.toml, a sample configuration is shown below. It is expected that the user already have a working GNU compiler toolchain and update the paths accordingly.
|
||||
Therefore, you can build Rust with support for the target by adding it to the target list in bootstrap.toml, a sample configuration is shown below. It is expected that the user already have a working GNU compiler toolchain and update the paths accordingly.
|
||||
|
||||
```toml
|
||||
[llvm]
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ This target generates binaries in the ELF format.
|
|||
## Building the target
|
||||
|
||||
You can build Rust with support for the target by adding it to the `target`
|
||||
list in `config.toml` and providing paths to the devkitARM toolchain.
|
||||
list in `bootstrap.toml` and providing paths to the devkitARM toolchain.
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ If you don't already have a suitable toolchain, download one [here](https://tool
|
|||
|
||||
### Configure rust
|
||||
|
||||
The target can be built by enabling it for a `rustc` build, by placing the following in `config.toml`:
|
||||
The target can be built by enabling it for a `rustc` build, by placing the following in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ If you don't already have a suitable toolchain, you can download from [here](htt
|
|||
|
||||
### Configure rust
|
||||
|
||||
The target can be built by enabling it for a `rustc` build, by placing the following in `config.toml`:
|
||||
The target can be built by enabling it for a `rustc` build, by placing the following in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -180,7 +180,7 @@ Fuchsia as well. A recent version (14+) of clang should be sufficient to compile
|
|||
Rust for Fuchsia.
|
||||
|
||||
x86-64 and AArch64 Fuchsia targets can be enabled using the following
|
||||
configuration in `config.toml`:
|
||||
configuration in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
@ -212,7 +212,7 @@ cxx = "clang++"
|
|||
|
||||
By default, the Rust compiler installs itself to `/usr/local` on most UNIX
|
||||
systems. You may want to install it to another location (e.g. a local `install`
|
||||
directory) by setting a custom prefix in `config.toml`:
|
||||
directory) by setting a custom prefix in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[install]
|
||||
|
|
@ -695,7 +695,7 @@ We can then use the script to start our test environment with:
|
|||
)
|
||||
```
|
||||
|
||||
Where `${RUST_SRC_PATH}/build` is the `build-dir` set in `config.toml`.
|
||||
Where `${RUST_SRC_PATH}/build` is the `build-dir` set in `bootstrap.toml`.
|
||||
|
||||
Once our environment is started, we can run our tests using `x.py` as usual. The
|
||||
test runner script will run the compiled tests on an emulated Fuchsia device. To
|
||||
|
|
@ -705,7 +705,7 @@ run the full `tests/ui` test suite:
|
|||
( \
|
||||
source config-env.sh && \
|
||||
./x.py \
|
||||
--config config.toml \
|
||||
--config bootstrap.toml \
|
||||
--stage=2 \
|
||||
test tests/ui \
|
||||
--target x86_64-unknown-fuchsia \
|
||||
|
|
@ -893,7 +893,7 @@ through our `x.py` invocation. The full invocation is:
|
|||
( \
|
||||
source config-env.sh && \
|
||||
./x.py \
|
||||
--config config.toml \
|
||||
--config bootstrap.toml \
|
||||
--stage=2 \
|
||||
test tests/${TEST} \
|
||||
--target x86_64-unknown-fuchsia \
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ Hermit binaries have the ELF format.
|
|||
|
||||
## Building the target
|
||||
|
||||
You can build Rust with support for the targets by adding it to the `target` list in `config.toml`.
|
||||
You can build Rust with support for the targets by adding it to the `target` list in `bootstrap.toml`.
|
||||
To run the Hermit build scripts, you also have to enable your host target.
|
||||
The build scripts rely on `llvm-tools` and binaries are linked using `rust-lld`, so those have to be enabled as well.
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ Because it is Tier 3, rust does not yet ship pre-compiled artifacts for this
|
|||
target.
|
||||
|
||||
Therefore, you can build Rust with support for the target by adding it to the
|
||||
target list in `config.toml`, a sample configuration is shown below.
|
||||
target list in `bootstrap.toml`, a sample configuration is shown below.
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ This target generates PIC ELF binaries.
|
|||
## Building the target
|
||||
|
||||
You can build Rust with support for the target by adding it to the `target`
|
||||
list in `config.toml`:
|
||||
list in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ You'll need the macOS 10.13 SDK shipped with Xcode 9. The location of the SDK
|
|||
can be passed to `rustc` using the common `SDKROOT` environment variable.
|
||||
|
||||
Once you have that, you can build Rust with support for the target by adding
|
||||
it to the `target` list in `config.toml`:
|
||||
it to the `target` list in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ The target can be built by enabling it for a `rustc` build.
|
|||
target = ["aarch64-kmc-solid_asp3"]
|
||||
```
|
||||
|
||||
Make sure `aarch64-kmc-elf-gcc` is included in `$PATH`. Alternatively, you can use GNU Arm Embedded Toolchain by adding the following to `config.toml`:
|
||||
Make sure `aarch64-kmc-elf-gcc` is included in `$PATH`. Alternatively, you can use GNU Arm Embedded Toolchain by adding the following to `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[target.aarch64-kmc-solid_asp3]
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ These targets are distributed through `rustup`, and otherwise require no
|
|||
special configuration.
|
||||
|
||||
If you need to build your own Rust for some reason though, the targets can be
|
||||
simply enabled in `config.toml`. For example:
|
||||
simply enabled in `bootstrap.toml`. For example:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
@ -73,7 +73,7 @@ target = ["loongarch64-unknown-linux-gnu"]
|
|||
```
|
||||
|
||||
Make sure the LoongArch toolchain binaries are reachable from `$PATH`.
|
||||
Alternatively, you can explicitly configure the paths in `config.toml`:
|
||||
Alternatively, you can explicitly configure the paths in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[target.loongarch64-unknown-linux-gnu]
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ scripts.
|
|||
## Building the target
|
||||
|
||||
You can build Rust with support for the targets by adding them to the `target`
|
||||
list in `config.toml`:
|
||||
list in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ The following procedure outlines the build process for the MIPS64 R6 target with
|
|||
|
||||
### Prerequisite: Disable debuginfo
|
||||
|
||||
An LLVM bug makes rustc crash if debug or debug info generation is enabled. You need to edit `config.toml` to disable this:
|
||||
An LLVM bug makes rustc crash if debug or debug info generation is enabled. You need to edit `bootstrap.toml` to disable this:
|
||||
|
||||
```toml
|
||||
[rust]
|
||||
|
|
@ -83,7 +83,7 @@ The crate `rustix` may try to link itself against MIPS R2 assembly, resulting in
|
|||
export RUSTFLAGS="--cfg rustix_use_libc"
|
||||
```
|
||||
|
||||
This will trigger warnings during build, as `-D warnings` is enabled by default. Disable `-D warnings` by editing `config.toml` to append the following:
|
||||
This will trigger warnings during build, as `-D warnings` is enabled by default. Disable `-D warnings` by editing `bootstrap.toml` to append the following:
|
||||
|
||||
```toml
|
||||
[rust]
|
||||
|
|
@ -116,7 +116,7 @@ target = ["mipsisa64r6el-unknown-linux-gnuabi64"]
|
|||
|
||||
Make sure that `mipsisa64r6el-unknown-linux-gnuabi64-gcc` is available from your executable search path (`$PATH`).
|
||||
|
||||
Alternatively, you can specify the directories to all necessary toolchain executables in `config.toml`:
|
||||
Alternatively, you can specify the directories to all necessary toolchain executables in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[target.mipsisa64r6el-unknown-linux-gnuabi64]
|
||||
|
|
|
|||
|
|
@ -124,7 +124,7 @@ For conditional compilation, following QNX specific attributes are defined:
|
|||
|
||||
## Building the target
|
||||
|
||||
1. Create a `config.toml`
|
||||
1. Create a `bootstrap.toml`
|
||||
|
||||
Example content:
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ What format do binaries use by default? ELF, PE, something else?
|
|||
## Building the target
|
||||
|
||||
If Rust doesn't build the target by default, how can users build it? Can users
|
||||
just add it to the `target` list in `config.toml`?
|
||||
just add it to the `target` list in `bootstrap.toml`?
|
||||
|
||||
## Building Rust programs
|
||||
|
||||
|
|
|
|||
|
|
@ -145,7 +145,7 @@ linker = "/path/to/x86_64-unknown-linux-ohos-clang.sh"
|
|||
## Building the target from source
|
||||
|
||||
Instead of using `rustup`, you can instead build a rust toolchain from source.
|
||||
Create a `config.toml` with the following contents:
|
||||
Create a `bootstrap.toml` with the following contents:
|
||||
|
||||
```toml
|
||||
profile = "compiler"
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Like with any other Windows target, created binaries are in PE format.
|
|||
|
||||
These targets can be easily cross-compiled
|
||||
using [llvm-mingw](https://github.com/mstorsjo/llvm-mingw) toolchain or [MSYS2 CLANG*](https://www.msys2.org/docs/environments/) environments.
|
||||
Just fill `[target.*]` sections for both build and resulting compiler and set installation prefix in `config.toml`.
|
||||
Just fill `[target.*]` sections for both build and resulting compiler and set installation prefix in `bootstrap.toml`.
|
||||
Then run `./x.py install`.
|
||||
In my case I had ran `./x.py install --host x86_64-pc-windows-gnullvm --target x86_64-pc-windows-gnullvm` inside MSYS2 MINGW64 shell
|
||||
so `x86_64-pc-windows-gnu` was my build toolchain.
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ The target can be built by enabling it for a `rustc` build.
|
|||
target = ["powerpc64le-unknown-linux-musl"]
|
||||
```
|
||||
|
||||
Make sure your C compiler is included in `$PATH`, then add it to the `config.toml`:
|
||||
Make sure your C compiler is included in `$PATH`, then add it to the `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[target.powerpc64le-unknown-linux-musl]
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Redox OS binaries use ELF as file format.
|
|||
|
||||
## Building the target
|
||||
|
||||
You can build Rust with support for the targets by adding it to the `target` list in `config.toml`. In addition a copy of [relibc] needs to be present in the linker search path.
|
||||
You can build Rust with support for the targets by adding it to the `target` list in `bootstrap.toml`. In addition a copy of [relibc] needs to be present in the linker search path.
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ Calling `extern "C"` on the target uses the C calling convention outlined in the
|
|||
## Building for the zkVM
|
||||
|
||||
Programs for the zkVM could be built by adding it to the `target` list in
|
||||
`config.toml`. However, we recommend building programs in our starter template
|
||||
`bootstrap.toml`. However, we recommend building programs in our starter template
|
||||
generated by the [cargo-risczero] utility and the [risc0-build] crate. This
|
||||
crate calls `rustc` with `-C "link-arg=-Ttext=` so that it maps the text in the
|
||||
appropriate location as well as generating variables that represent the ELF and
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ The target can be built by enabling it for a `rustc` build.
|
|||
target = ["riscv32imac-unknown-xous-elf"]
|
||||
```
|
||||
|
||||
Make sure your C compiler is included in `$PATH`, then add it to the `config.toml`:
|
||||
Make sure your C compiler is included in `$PATH`, then add it to the `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[target.riscv32imac-unknown-xous-elf]
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ These targets are distributed through `rustup`, and otherwise require no
|
|||
special configuration.
|
||||
|
||||
If you need to build your own Rust for some reason though, the targets can be
|
||||
enabled in `config.toml`. For example:
|
||||
enabled in `bootstrap.toml`. For example:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ The target can be built by enabling it for a `rustc` build.
|
|||
target = ["riscv64gc-unknown-linux-musl"]
|
||||
```
|
||||
|
||||
Make sure your C compiler is included in `$PATH`, then add it to the `config.toml`:
|
||||
Make sure your C compiler is included in `$PATH`, then add it to the `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[target.riscv64gc-unknown-linux-musl]
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ This target is distributed through `rustup`, and otherwise requires no
|
|||
special configuration.
|
||||
|
||||
If you need to build your own Rust for some reason though, the target can be
|
||||
enabled in `config.toml`. For example:
|
||||
enabled in `bootstrap.toml`. For example:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Because it is Tier 3, Rust does not yet ship pre-compiled artifacts for this
|
|||
target.
|
||||
|
||||
Therefore, you can build Rust with support for the target by adding it to the
|
||||
target list in `config.toml`, a sample configuration is shown below.
|
||||
target list in `bootstrap.toml`, a sample configuration is shown below.
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ considerations for binary layout will require linker options or linker scripts.
|
|||
## Building the target
|
||||
|
||||
You can build Rust with support for the target by adding it to the `target`
|
||||
list in `config.toml`:
|
||||
list in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Instead, the Unikraft build system will produce the final Unikernel image for th
|
|||
|
||||
## Building the targets
|
||||
|
||||
You can build Rust with support for the targets by adding it to the `target` list in `config.toml`:
|
||||
You can build Rust with support for the targets by adding it to the `target` list in `bootstrap.toml`:
|
||||
|
||||
```toml
|
||||
[build]
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue