This also makes some other minor cleanups:
- Suggest `python x.py` on windows instead of `./x.py`, which usually
doesn't work
- Move the "Configure and Make" section to a subsection of "Building on
Unix"
- Mention `config.toml` earlier
- Suggest `x.py setup user` on Windows, since `configure` won't work
The other places are more accurate and up-to-date.
- Link to `std-dev-guide` in CONTRIBUTING.md
Thom and Mara said the guide is in reasonably good shape, and it's tailored more closely to people working on the standard library.
- Link to CONTRIBUTING.md instead of rustc-dev-guide in the main readme
CONTRIBUTING.md has more information and also links the std-dev-guide.
- Link to forge for the list of tested platforms; the one in the readme
was hopelessly out of date.
This is implementing the MCP from rust-lang/compiler-team#493. It is
increasing the minimum requirements of a couple Tier 1 targets, and
others at lower tiers, so this should go through FCP sign-offs for both
`T-compiler` and `T-release`.
The new `linux-gnu` baseline is kernel 3.2 and glibc 2.17. We will also
take that kernel as the minimum floor for _all_ `*-linux-*` targets, so
it may be broadly assumed in the implementation of the standard library.
That does not preclude specific targets from having greater requirements
where it makes sense, like a new arch needing something newer, or a
platform like `linux-android` choosing a newer baseline.
Doc Jones mentioned that one of the things making it hard to get started
is that the amount of information is overwhelming, between the
dev-guide, contributing guide, and discussion platforms. This gives
people a single link they can click to ask for help.
This change adds pre-setup instructions that outline how x.py requires
python to be setup and how to work around the problem of x.py failing to
locate python, especially now that Ubuntu 20.04's dropped default python
command is causing people to encounter this issue regularly.
See also: #71818
Added the `mingw-w64-x86_64-ninja` package to the build guide for MinGW, as well as a note not to use the `ninja` package from the `msys2` subsystem (doesn't handle paths correctly on windows).
Ninja substantially improves LLVM build time. On a 96-way system, using
Make took 248s, and using Ninja took 161s, a 35% improvement.
We already require a variety of tools to build Rust. If someone wants to
build without Ninja (for instance, to minimize the set of packages
required to bootstrap a new target), they can easily set `ninja=false`
in `config.toml`. Our defaults should help people build Rust (and LLVM)
faster, to speed up development.
Zander Milroy