From 19e52b52f23dcaf7dbe79e5a34426fe6987a0d93 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Fri, 18 Sep 2026 19:43:46 +0200 Subject: [PATCH 1/2] Revert "improve tests/ecosystem-test-jobs/fuchsia.md" This reverts commit 0bb5cd0fb339d3d1765af05fc1411a5742cb9d12. --- src/tests/ecosystem-test-jobs/fuchsia.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/tests/ecosystem-test-jobs/fuchsia.md b/src/tests/ecosystem-test-jobs/fuchsia.md index edbb3b93a0..124e8dfcda 100644 --- a/src/tests/ecosystem-test-jobs/fuchsia.md +++ b/src/tests/ecosystem-test-jobs/fuchsia.md @@ -47,7 +47,7 @@ The main reason you would want to build Fuchsia locally is because you need to investigate a regression. After running a Docker build, you'll find the Fuchsia checkout inside the `obj/fuchsia` directory of your Rust checkout. -If you modify the `KEEP_CHECKOUT` line in the [build-fuchsia.sh] script to + If you modify the `KEEP_CHECKOUT` line in the [build-fuchsia.sh] script to `KEEP_CHECKOUT=1`, you can change the checkout as needed and rerun the build command above. This will reuse all the build results from before. @@ -70,11 +70,11 @@ There are a few `fx` subcommands that are relevant, including: - `fx set` accepts build arguments, writes them to `out/default/args.gn`, and runs GN. - `fx build` builds the Fuchsia project using Ninja. It will automatically pick up changes to build arguments and rerun GN. - By default, it builds everything, + By default it builds everything, but it also accepts target paths to build specific targets (see below). - `fx clippy` runs Clippy on specific Rust targets (or all of them). We use this in the Rust CI build to avoid running codegen on most Rust targets. - Underneath, it invokes Ninja, just like `fx build`. + Underneath it invokes Ninja, just like `fx build`. The clippy results are saved in json files inside the build output directory before being printed. @@ -135,7 +135,7 @@ Once you have the command, you can run it from inside the output directory. After changing the toolchain itself, the build setting `rustc_version_string` in `out/default/args.gn` needs to be changed so that `fx build` or `ninja` will rebuild all the Rust targets. -This can be done in a text editor, and the contents of the string do not matter, +This can be done in a text editor and the contents of the string do not matter, as long as it changes from one build to the next. [build_fuchsia_from_rust_ci.sh] does this for you by hashing the toolchain directory. @@ -145,7 +145,7 @@ The Fuchsia website has more detailed documentation of the [build system]. When using `build_fuchsia_from_rust_ci.sh` you can comment out the `fx set` command after the initial run so it won't rerun GN each time. -If you do this, you can also comment out the version_string line to save a few seconds. +If you do this you can also comment out the version_string line to save a couple seconds. `export NINJA_PERSISTENT_MODE=1` to get faster ninja startup times after the initial build. From 76e374ad611d5dd72eecbf7e595a2e447df83a1f Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Fri, 18 Sep 2026 19:44:08 +0200 Subject: [PATCH 2/2] Revert "sembr src/tests/ecosystem-test-jobs/fuchsia.md" This reverts commit fcfdbf39d50bf291f24b55ce4d3d80939f4f7f37. --- src/tests/ecosystem-test-jobs/fuchsia.md | 98 ++++++++++++------------ 1 file changed, 50 insertions(+), 48 deletions(-) diff --git a/src/tests/ecosystem-test-jobs/fuchsia.md b/src/tests/ecosystem-test-jobs/fuchsia.md index 124e8dfcda..75cf782a77 100644 --- a/src/tests/ecosystem-test-jobs/fuchsia.md +++ b/src/tests/ecosystem-test-jobs/fuchsia.md @@ -14,7 +14,8 @@ Please contact the [fuchsia][fuchsia-ping] ping group and ask them for help. ## Building Fuchsia in CI -Fuchsia builds as part of the suite of bors tests that run before a pull request is merged. +Fuchsia builds as part of the suite of bors tests that run before a pull request +is merged. If you are worried that a pull request might break the Fuchsia builder and want to test it out before submitting it to the bors queue, simply ask bors to run @@ -22,13 +23,13 @@ the try job that builds the Fuchsia integration: `@bors try jobs=x86_64-fuchsia` ## Building Fuchsia locally -Because Fuchsia uses languages other than Rust, it does not use Cargo as a build system. -It also requires the toolchain build to be configured in a [certain way][build-toolchain]. +Because Fuchsia uses languages other than Rust, it does not use Cargo as a build +system. It also requires the toolchain build to be configured in a [certain +way][build-toolchain]. The recommended way to build Fuchsia is to use the Docker scripts that check out -and run a Fuchsia build for you. -If you've run Docker tests before, -you can simply run this command from your Rust checkout to download and build Fuchsia +and run a Fuchsia build for you. If you've run Docker tests before, you can +simply run this command from your Rust checkout to download and build Fuchsia using your local Rust toolchain. ``` @@ -39,19 +40,20 @@ See the [Testing with Docker](../docker.md) chapter for more details on how to r and debug jobs with Docker. Note that a Fuchsia checkout is *large* – as of this writing, a checkout and -build takes 46G of space – and as you might imagine, it takes a while to complete. +build takes 46G of space – and as you might imagine, it takes a while to +complete. ### Modifying the Fuchsia checkout The main reason you would want to build Fuchsia locally is because you need to -investigate a regression. -After running a Docker build, -you'll find the Fuchsia checkout inside the `obj/fuchsia` directory of your Rust checkout. - If you modify the `KEEP_CHECKOUT` line in the [build-fuchsia.sh] script to -`KEEP_CHECKOUT=1`, you can change the checkout as needed and rerun the build command above. -This will reuse all the build results from before. +investigate a regression. After running a Docker build, you'll find the Fuchsia +checkout inside the `obj/fuchsia` directory of your Rust checkout. If you +modify the `KEEP_CHECKOUT` line in the [build-fuchsia.sh] script to +`KEEP_CHECKOUT=1`, you can change the checkout as needed and rerun the build +command above. This will reuse all the build results from before. -You can find more options to customize the Fuchsia checkout in the [build-fuchsia.sh] script. +You can find more options to customize the Fuchsia checkout in the +[build-fuchsia.sh] script. ### Customizing the Fuchsia build @@ -67,15 +69,14 @@ to add this to your `$PATH` for some workflows. There are a few `fx` subcommands that are relevant, including: -- `fx set` accepts build arguments, writes them to `out/default/args.gn`, and runs GN. -- `fx build` builds the Fuchsia project using Ninja. - It will automatically pick up changes to build arguments and rerun GN. - By default it builds everything, +- `fx set` accepts build arguments, writes them to `out/default/args.gn`, and + runs GN. +- `fx build` builds the Fuchsia project using Ninja. It will automatically pick + up changes to build arguments and rerun GN. By default it builds everything, but it also accepts target paths to build specific targets (see below). -- `fx clippy` runs Clippy on specific Rust targets (or all of them). - We use this in the Rust CI build to avoid running codegen on most Rust targets. - Underneath it invokes Ninja, just like `fx build`. - The clippy results are saved in json +- `fx clippy` runs Clippy on specific Rust targets (or all of them). We use this + in the Rust CI build to avoid running codegen on most Rust targets. Underneath + it invokes Ninja, just like `fx build`. The clippy results are saved in json files inside the build output directory before being printed. #### Target paths @@ -86,20 +87,20 @@ GN uses paths like the following to identify build targets: //src/starnix/kernel:starnix_core ``` -The initial `//` means the root of the checkout, and the remaining slashes are directory names. -The string after `:` is the _target name_ of a target defined +The initial `//` means the root of the checkout, and the remaining slashes are +directory names. The string after `:` is the _target name_ of a target defined in the `BUILD.gn` file of that directory. -The target name can be omitted if it is the same as the directory name. -In other words, `//src/starnix/kernel` is the same as `//src/starnix/kernel:kernel`. +The target name can be omitted if it is the same as the directory name. In other +words, `//src/starnix/kernel` is the same as `//src/starnix/kernel:kernel`. These target paths are used inside `BUILD.gn` files to reference dependencies, and can also be used in `fx build`. #### Modifying compiler flags -You can put custom compiler flags inside a GN `config` that is added to a target. -As a simple example: +You can put custom compiler flags inside a GN `config` that is added to a +target. As a simple example: ``` config("everybody_loops") { @@ -113,20 +114,20 @@ rustc_binary("example") { } ``` -This will add the flag `-Zeverybody-loops` to rustc when building the `example` target. -Note that you can also use [`public_configs`] for a config to be added +This will add the flag `-Zeverybody-loops` to rustc when building the `example` +target. Note that you can also use [`public_configs`] for a config to be added to every target that depends on that target. -If you want to add a flag to every Rust target in the build, -you can add rustflags to the [`//build/config:compiler`] config or to the OS-specific -configs referenced in that file. -Note that `cflags` and `ldflags` are ignored on Rust targets. +If you want to add a flag to every Rust target in the build, you can add +rustflags to the [`//build/config:compiler`] config or to the OS-specific +configs referenced in that file. Note that `cflags` and `ldflags` are ignored on +Rust targets. #### Running ninja and rustc commands directly -Going down one layer, `fx build` invokes `ninja`, which in turn eventually invokes `rustc`. -All build actions are run inside the out directory, -which is usually `out/default` inside the Fuchsia checkout. +Going down one layer, `fx build` invokes `ninja`, which in turn eventually +invokes `rustc`. All build actions are run inside the out directory, which is +usually `out/default` inside the Fuchsia checkout. You can get ninja to print the actual command it invokes by forcing that command to fail, e.g. by adding a syntax error to one of the source files of the target. @@ -134,25 +135,26 @@ Once you have the command, you can run it from inside the output directory. After changing the toolchain itself, the build setting `rustc_version_string` in `out/default/args.gn` needs to be changed so that `fx build` or `ninja` will -rebuild all the Rust targets. -This can be done in a text editor and the contents of the string do not matter, -as long as it changes from one build to the next. -[build_fuchsia_from_rust_ci.sh] does this for you by hashing the toolchain directory. +rebuild all the Rust targets. This can be done in a text editor and the contents +of the string do not matter, as long as it changes from one build to the next. +[build_fuchsia_from_rust_ci.sh] does this for you by hashing the toolchain +directory. The Fuchsia website has more detailed documentation of the [build system]. #### Other tips and tricks When using `build_fuchsia_from_rust_ci.sh` you can comment out the `fx set` -command after the initial run so it won't rerun GN each time. -If you do this you can also comment out the version_string line to save a couple seconds. +command after the initial run so it won't rerun GN each time. If you do this you +can also comment out the version_string line to save a couple seconds. -`export NINJA_PERSISTENT_MODE=1` to get faster ninja startup times after the initial build. +`export NINJA_PERSISTENT_MODE=1` to get faster ninja startup times after the +initial build. ## Fuchsia target support -To learn more about Fuchsia target support, -see the Fuchsia chapter in [the rustc book][platform-support]. +To learn more about Fuchsia target support, see the Fuchsia chapter in [the +rustc book][platform-support]. [regressions]: https://gist.github.com/tmandry/7103eba4bd6a6fb0c439b5a90ae355fa [build-toolchain]: https://fuchsia.dev/fuchsia-src/development/build/rust_toolchain @@ -167,5 +169,5 @@ see the Fuchsia chapter in [the rustc book][platform-support]. [fuchsia-ping]: ../../notification-groups/fuchsia.md [^loc]: As of June 2024, Fuchsia had about 2 million lines of first-party Rust -code and a roughly equal amount of third-party code, -as counted by tokei (excluding comments and blanks). +code and a roughly equal amount of third-party code, as counted by tokei +(excluding comments and blanks).