Remove ancient and outdated references to config.mk

This commit is contained in:
Joshua Nelson 2022-12-23 19:03:51 -06:00
parent 1bd1b25be8
commit 70a0e0a277
3 changed files with 4 additions and 15 deletions

View File

@ -228,9 +228,7 @@ configure script and makefile (the latter of which just invokes `x.py`).
make && sudo make install
```
When using the configure script, the generated `config.mk` file may override the
`config.toml` file. To go back to the `config.toml` file, delete the generated
`config.mk` file.
`configure` generates a `config.toml` which can also be used with normal `x.py` invocations.
## Building Documentation

View File

@ -80,18 +80,12 @@ The script accepts commands, flags, and arguments to determine what to do:
## Configuring rustbuild
There are currently two methods for configuring the rustbuild build system.
First, rustbuild offers a TOML-based configuration system with a `config.toml`
rustbuild offers a TOML-based configuration system with a `config.toml`
file. An example of this configuration can be found at `config.toml.example`,
and the configuration file can also be passed as `--config path/to/config.toml`
if the build system is being invoked manually (via the python script).
Next, the `./configure` options serialized in `config.mk` will be
parsed and read. That is, if any `./configure` options are passed, they'll be
handled naturally. `./configure` should almost never be used for local
installations, and is primarily useful for CI. Prefer to customize behavior
using `config.toml`.
You can generate a config.toml using `./configure` options if you want to automate creating the file without having to edit it.
Finally, rustbuild makes use of the [cc-rs crate] which has [its own
method][env-vars] of configuring C compilers and C flags via environment

View File

@ -46,10 +46,7 @@ pub enum DryRun {
/// Global configuration for the entire build and/or bootstrap.
///
/// This structure is derived from a combination of both `config.toml` and
/// `config.mk`. As of the time of this writing it's unlikely that `config.toml`
/// is used all that much, so this is primarily filled out by `config.mk` which
/// is generated from `./configure`.
/// This structure is parsed from `config.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