Skip to content

Commit 87be918

Browse files
committed
docs(dev-guide): mention how to support new compilation targets
1 parent 17c3406 commit 87be918

2 files changed

Lines changed: 58 additions & 1 deletion

File tree

doc/dev-guide/src/SUMMARY.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,10 @@
11
# Summary
22

33
- [Introduction](index.md)
4-
- [Linting](linting.md)
4+
- [Linting](linting.md)
55
- [Coding standards](coding-standards.md)
66
- [Version numbers](version-numbers.md)
7+
- [Recipes](recipes.md)
78
- [Release process](release-process.md)
89
- [Tips and tricks](tips-and-tricks.md)
910
- [Tracing](tracing.md)

doc/dev-guide/src/recipes.md

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
# Recipes
2+
3+
This section contains some recipes for common tasks that you may want to
4+
perform when contributing to rustup.
5+
6+
## Supporting a new tier 2 target with host tools
7+
8+
In principle, all target tuples **with host tools** should be recognized by
9+
rustup and have its official rustup builds. Thus, once a new target has been
10+
promoted to tier 2 with host tools, it should also be explicitly supported by
11+
rustup through the following steps:
12+
13+
1. Informing rustup of the new target:
14+
15+
At the moment of writing, GitHub Actions' runners natively support Linux,
16+
Windows, and macOS. Tier 2 builds are mostly cross-compiled from Linux
17+
(except for Windows and macOS targets, which are directly compiled from the
18+
target platform), and thus we will be focusing on the Linux case below.
19+
20+
You can refer to [rustup#4688] for a practical example for adding a new tier
21+
2 target via cross-builds from Linux, where you can find nearly all places
22+
where you would need to mention your new target in the rustup codebase.
23+
24+
Notably, you would need to add a line in
25+
`ci/actions-templates/linux-builds-template.yaml` to include it in rustup's
26+
CI, while disabling the build for this target in all scenarios. At the
27+
moment of writing, this is done by appending the YAML comment
28+
`# skip-pr skip-master skip-stable`
29+
at the end of the line when mentioning your target in that file.
30+
31+
On the other hand, if you need to support new Windows or macOS targets,
32+
please don't hesitate to discuss this with the team in a dedicated [rustup
33+
issue].
34+
35+
[rustup#4688]: https://github.com/rust-lang/rustup/pull/4688
36+
[rustup issue]: https://github.com/rust-lang/rustup/issues
37+
38+
2. Stabilizing the target:
39+
40+
When your new target reaches stable Rust, you can then enable the target in
41+
certain CI scenarios, depending on the popularity of the target. At the
42+
moment of writing, this is done by removing certain occurrences of `skip-*`
43+
in the aforementioned YAML comment. In most cases, you would only need to
44+
enable the target for the `stable` CI scenario by removing `skip-stable`.
45+
46+
You can refer to [rustup#4816] for a practical example for this step.
47+
48+
Do note that when creating the PR for this step, you will need to prove that
49+
the target's CI is indeed working by removing `skip-pr` in a separate commit
50+
to temporarily enable this target in this PR's CI. Once the CI is green, you
51+
can send the link ([example][send-link]) to that CI run in the PR thread for
52+
verification. After that, you can safely drop the temporary commit to get
53+
the PR ready for merging.
54+
55+
[rustup#4816]: https://github.com/rust-lang/rustup/pull/4816
56+
[send-link]: https://github.com/rust-lang/rustup/pull/4816#issuecomment-4263419604

0 commit comments

Comments
 (0)