|
6 | 6 | //! to a new platform, and allows for an unprecedented level of control over how
|
7 | 7 | //! the compiler works.
|
8 | 8 | //!
|
9 |
| -//! # Using custom targets |
| 9 | +//! # Using targets and target.json |
10 | 10 | //!
|
11 |
| -//! A target tuple, as passed via `rustc --target=TUPLE`, will first be |
12 |
| -//! compared against the list of built-in targets. This is to ease distributing |
13 |
| -//! rustc (no need for configuration files) and also to hold these built-in |
14 |
| -//! targets as immutable and sacred. If `TUPLE` is not one of the built-in |
15 |
| -//! targets, rustc will check if a file named `TUPLE` exists. If it does, it |
16 |
| -//! will be loaded as the target configuration. If the file does not exist, |
17 |
| -//! rustc will search each directory in the environment variable |
18 |
| -//! `RUST_TARGET_PATH` for a file named `TUPLE.json`. The first one found will |
19 |
| -//! be loaded. If no file is found in any of those directories, a fatal error |
20 |
| -//! will be given. |
| 11 | +//! Invoking "rustc --target=${TUPLE}" will result in rustc initiating the [`Target::search`] by |
| 12 | +//! - checking if "$TUPLE" is a complete path to a json (ending with ".json") and loading if so |
| 13 | +//! - checking builtin targets for "${TUPLE}" |
| 14 | +//! - checking directories in "${RUST_TARGET_PATH}" for "${TUPLE}.json" |
| 15 | +//! - checking for "${RUSTC_SYSROOT}/lib/rustlib/${TUPLE}/target.json" |
21 | 16 | //!
|
22 |
| -//! Projects defining their own targets should use |
23 |
| -//! `--target=path/to/my-awesome-platform.json` instead of adding to |
24 |
| -//! `RUST_TARGET_PATH`. |
| 17 | +//! Code will then be compiled using the first discovered target spec. |
25 | 18 | //!
|
26 | 19 | //! # Defining a new target
|
27 | 20 | //!
|
28 |
| -//! Targets are defined using [JSON](https://json.org/). The `Target` struct in |
29 |
| -//! this module defines the format the JSON file should take, though each |
30 |
| -//! underscore in the field names should be replaced with a hyphen (`-`) in the |
31 |
| -//! JSON file. Some fields are required in every target specification, such as |
32 |
| -//! `llvm-target`, `target-endian`, `target-pointer-width`, `data-layout`, |
33 |
| -//! `arch`, and `os`. In general, options passed to rustc with `-C` override |
34 |
| -//! the target's settings, though `target-feature` and `link-args` will *add* |
35 |
| -//! to the list specified by the target, rather than replace. |
| 21 | +//! Targets are defined using a struct which additionally has serialization to and from [JSON]. |
| 22 | +//! The `Target` struct in this module loosely corresponds with the format the JSON takes. |
| 23 | +//! We usually try to make the fields equivalent but we have given up on a 1:1 correspondence |
| 24 | +//! between the JSON and the actual structure itself. |
| 25 | +//! |
| 26 | +//! Some fields are required in every target spec, and they should be embedded in Target directly. |
| 27 | +//! Optional keys are in TargetOptions, but Target derefs to it, for no practical difference. |
| 28 | +//! Most notable is the "data-layout" field which specifies Rust's notion of sizes and alignments |
| 29 | +//! for several key types, such as f64, pointers, and so on. |
| 30 | +//! |
| 31 | +//! At one point we felt `-C` options should override the target's settings, like in C compilers, |
| 32 | +//! but that was an essentially-unmarked route for making code incorrect and Rust unsound. |
| 33 | +//! Confronted with programmers who prefer a compiler with a good UX instead of a lethal weapon, |
| 34 | +//! we have almost-entirely recanted that notion, though we hope "target modifiers" will offer |
| 35 | +//! a way to have a decent UX yet still extend the necessary compiler controls, without |
| 36 | +//! requiring a new target spec for each and every single possible target micro-variant. |
| 37 | +//! |
| 38 | +//! [JSON]: https://json.org |
36 | 39 |
|
37 | 40 | use std::borrow::Cow;
|
38 | 41 | use std::collections::BTreeMap;
|
|
0 commit comments