Fwd: PSA: Chromium's build system is switching from Ninja to Siso for external developers

[Junji Watanabe]

Hi Reclient users, 

I sent a PSA about switching the build system from Ninja to Siso.

Reclient will be deleted from Chromium dependency at the end of September.
We would love to discuss how you can migrate from Ninja/Reclient to Siso.

Please let me know how you currently use Reclient for Chromium builds. e.g. which REAPI backends, authentication etc

Regards,

Junji

---------- Forwarded message ---------
From: Junji Watanabe <jw...@google.com>
Date: Mon, Jun 16, 2025 at 6:00 PM
Subject: PSA: Chromium's build system is switching from Ninja to Siso for external developers
To: chromi...@chromium.org <chromi...@chromium.org>
Cc: bu...@chromium.org <bu...@chromium.org>

Hi everyone,

This PSA is for all external Chromium developers regarding an upcoming change to the Chromium build system.

What's changing?

Chromium's build system is switching from Ninja 🥷 to Siso 🌿. This migration has already been completed for developers and CI/CQ within Google, and we are now extending it to our external contributors.

Siso is developed by the Chrome Build Infra Team at Google as a drop-in replacement for Ninja to support remote execution natively.

What do you need to do?

Just keep building Chromium with autoninja. autoninja will automatically use Siso after you run gn clean the next time.

How to opt out? 

If you encounter problems with Siso, you can switch back by setting use_siso=false in your args.gn.

About Ninja/Reclient/GN

• GN will stay the same as before.

• Reclient will be removed from Chromium at the end of September.

• Ninja will be unsupported after the end of September.

Please prepare to switch to Siso before the deadline.

Questions or Issues?

If you have any questions or run into any problems with this change, please don't hesitate to reach out to us:

• Slack: #build

• Chromium Issue Tracker: File a Siso bug.

• Email: bu...@chromium.org

Thanks,

Junji - on behalf of the Chrome Build Infra Team

[Yngve N. Pettersen]

Vivaldi's configuration is:

* Buildfarm with Linux workers, and cross-compile for Windows and Mac

* Two reclient scenarios

  * developers: remote execution, remote caching

  * Linux/Windows dev auto builders: local execution, remote caching

* Mac based autobuilders build locally, dev builds are using ccache (local caching)

* Official autobuilders are not using caching or remote executions, full rebuild locally each time

* Our source configuration is:

   * vivaldi repo "//vivaldi" or "//.."

    * ->  chromium repo "//" or "//vivaldi/chromium"

    * -> out build dir  "//out" or "//vivaldi/out"

* For reference, we maintain our own fork of GN, e.g to maintain the //vivaldi path mapping

Some related observations so far (with the caveat that I have not yet tested or extensively studied how siso actually works, this is based on first impressions):

* What the source/build dir configuration means is that the "//" restriction for Siso is a problem (our remote execution base path is "//vivaldi" , or "//../"). In my opinion there is no reason why it should be limited that way, it should work as a drop-in replacement of ninja, meaning that it runs in, and accesses file relative to, the build dir out/foo. Please remove that restriction. Siso may well have to find most of its configuration files using "//" as a path (but see next point), but we do not start our builds from the chromium dir, nor is the out dir mounted there. My suggestion is to split that config part out and isolate it from everything else.

* We also want ALL our environment specific remote execution/storage configuration files to be in the vivaldi repo, especially since we will have two different configurations (local execution and remote execution), this indicates that we need to be able to specify configuration dir paths when generating GN. Having them there also makes them more maintainable.

* Autoninja is AFAICT way too Google specific, and have functionality we do not need. We do not use depot_tools except using the third_party depot_tools submodule in very limited cases while running hooks or GN. This means that we would need to migrate the script to out tool repo, which would mean severely pruning the script. I am presently working to write our own more limited version, based on how we configure build modes.

* At present I do not want remote running of python script (or anything else, except clang related compile); that hesitancy is mostly a result of how the original GN remote action target (in BUILDCONFIG.gn) broke our GN generation step (I had to disable the functionality).

--
You received this message because you are subscribed to the Google Groups "reclient-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reclient-user...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/reclient-users/CAPi%2BNeWyoQD8sHRi4i%2B8o61GyeHN-e-g1k6eoX7UQjCpFC5UTA%40mail.gmail.com.

-- 
Sincerely,
Yngve N. Pettersen
Vivaldi Technologies AS

[John Kleinschmidt]

Electron uses Buildbarn with Linux workers, and we cross-compile for Windows and Mac.

We support a couple of reclient scenarios

• Maintainers have read/write access for remote execution/remote caching
• CI runs triggered by maintainers have read/write access for remote execution/remote caching
• Non-maintainers can sign in to receive a `Cache Only` token that gives read-only access to the cache-only CAS backend. 
• CI runs triggered by fork PRS/non-maintainers get read-only access to the cache-only CAS backend.

In regards to auth, we have our own custom RBE credential helper.

[Yngve N. Pettersen]

Hi again,

I have now done some testing.

* I was able to build locally (offline), but only by duplicating the //build/config/siso directory in our repo

* AFAICT I am not able to build remotely, unknown why, because there is AFAICT no information about connection status. In particular, I don't know if it is possible to ensure that only remote is used for clang

As the backend is internal network, there is no need to login.

The backend.star file have a field "container-image", which is confusing, since we are not using containers for our system. No need to use them, since the system is so small. So what we need is a way to specify just the backend name and port.

Additionally, we need to be able to switch between backend_dev.star and backend_builder.star, based on *GN variables*, not command line arguments

As I am able to build locally, at least, albeit with a duplicated config, indicates that there is really no problem with Siso running in a different base dir, as long as it can find the config dir, and IMO that does not have to be hardcoded relative to the current working directory. All the relevant information can easily be stored in the out/foo directory, including the backend.star file

Regarding remote execution, siso needs to provide a LOT more information about the connection status.

One observation: As fixes are no doubt needed, I think the september deadline is much too early, and should be moved to March 2026, at least.

We (Vivaldi) are currently developing based on Chromium 138. Our next Chromium version update will be to Extended Stable Chromium 140 in early August, and then Extended Stable Chromium 142 in early October. We will NOT be basing Vivaldi on Chromium 139, nor 141.

What that means is that for all Siso bugs to be fixed and any other major changes to be completed before the september deadline, ALL the problems (for Vivaldi, at least) have to be weeded out as part of either v138 or *before* the v140 branch-off (Aug 4); the 142 branch-off (Sep 29) will, given the stated schedule, be too late.