|
| 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