-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Rollup merge of #90498 - joshtriplett:target-tier-policy-draft-update…
…s, r=Mark-Simulacrum Clarifications in the target tier policy We've added several targets since the introduction of the target tier policy. Based on experiences of those adding such targets, and discussions around such additions, clarify the target tier policy to make it easier to follow and work with. None of these changes substantively change the requirements on targets. (In some cases the changes do direct target submitters to follow specific process requirements for the addition of a target, such as how to respond to requirements, where to put target-specific documentation, or what should appear in that documentation. Those changes are procedural in nature and document the procedures we already direct people to follow.) - Clarify how to quote and respond to the target tier policy requirements. Several times, people have seemed unclear on how to respond to some of the policy requirements, particularly those that just state things the target developers must *not* do (e.g. not posting to PRs that break the target). Add a note that such requirements just need acknowledgement, nothing more. - Clarify dependency requirements in the face of cross-compilation. I previously phrased this confusingly in terms of "host tools", since that is the case where an exception applies (allowing proprietary target libraries commonly used by binaries for the target). Rephrase it to apply equally to cross-compilation. This doesn't change the net effect of the requirements, since other requirements already cover the dependencies of the Rust toolchain. - Clarify documentation about running binaries. The requirement for target documentation talks about "running tests", but tier 3 targets often don't support running the full testsuite, and in practice the documentation for how to run an individual binary may be more useful. Change "running tests" to "running binaries, or running tests". - Explain where to place target-specific documentation (a subdirectory of platform-support, with a link from the platform-support entry for the target). - Add a template for target-specific documentation.
- Loading branch information
Showing
3 changed files
with
80 additions
and
16 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,52 @@ | ||
# `target-name-here` | ||
|
||
**Tier: 3** | ||
|
||
One-sentence description of the target (e.g. CPU, OS) | ||
|
||
## Target maintainers | ||
|
||
- Some Person, `[email protected]`, https://github.com/... | ||
|
||
## Requirements | ||
|
||
Does the target support host tools, or only cross-compilation? Does the target | ||
support std, or alloc (either with a default allocator, or if the user supplies | ||
an allocator)? | ||
|
||
Document the expectations of binaries built for the target. Do they assume | ||
specific minimum features beyond the baseline of the CPU/environment/etc? What | ||
version of the OS or environment do they expect? | ||
|
||
Are there notable `#[target_feature(...)]` or `-C target-feature=` values that | ||
programs may wish to use? | ||
|
||
What calling convention does `extern "C"` use on the target? | ||
|
||
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`? | ||
|
||
## Building Rust programs | ||
|
||
Rust does not yet ship pre-compiled artifacts for this target. To compile for | ||
this target, you will either need to build Rust with the target enabled (see | ||
"Building the target" above), or build your own copy of `core` by using | ||
`build-std` or similar. | ||
|
||
## Testing | ||
|
||
Does the target support running binaries, or do binaries have varying | ||
expectations that prevent having a standard way to run them? If users can run | ||
binaries, can they do so in some common emulator, or do they need native | ||
hardware? Does the target support running the Rust testsuite? | ||
|
||
## Cross-compilation toolchains and C code | ||
|
||
Does the target support C code? If so, what toolchain target should users use | ||
to build compatible C code? (This may match the target triple, or it may be a | ||
toolchain for a different target triple, potentially with specific options or | ||
caveats.) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters