[PSA] Deprecation of ninja binaries in depot_tools

[Junji Watanabe]

Hi,

We are deprecating ninja binaries checked into depot_tools. Going forward, projects should use Ninja installed from CIPD via their DEPS file instead. To make the migration easier for users, we have replaced the "ninja" command in depot_tools with a wrapper that runs Ninja from DEPS, but falls back to the legacy binary for now.

When is this happening?

Commit 1f67d55 has been submitted today, so all depot_tools synced afterwards will preferably trigger the "ninja" binary installed at the current gclient project by DEPS. (Example: chromium/src/third_party/ninja).

What do I need to do?

We have already added the ninja CIPD package to all known projects with DEPS. Running `gclient sync` is all you have to do in that case.

If you see a deprecation message “Fallback to a deprecated legacy ninja binary. Note that this ninja binary will be removed soon …”, you are still using the legacy binaries in depot_tools. 

Please install Ninja in your PATH.

Feel free to ask if you have any problems or questions.

Regards,

Junji - Chrome Browser Build team

[Tomasz Śniatowski]

Hi,

The depot_tools ninja wrapper mentions a restricted bug, https://crbug.com/1340825, when it does the fallback to depot tools binary:

    depot_tools/ninja.py: Fallback to a deprecated legacy ninja binary. Note that this ninja binary will be removed soon.
    Please install ninja to your project using DEPS. If your project does not have DEPS, Please install ninja in your PATH.
    See also https://crbug.com/1340825

Seems a bit unfortunate to link to an internal bug in a warning from a public tool. The design doc for deprecating depot tools ninja (linked in https://chromium-review.googlesource.com/c/chromium/src/+/3869740) is internal-only too afaik.

Anyway, I'm wondering what the intended solution is for people that need to work with Chromium and also non-DEPS projects or old versions of projects from before ninja was put in DEPS. Are there any official reasons against having people just run modern ninja locally, ignoring what's in DEPS/depot_tools? I'm worried that having "ninja" resolve to a different version based on CWD will be fragile considering people can do "ninja -C /abs/path", and would like to know what's the downside.

Regards,

Tomasz

[Junji Watanabe]

Hi Tomasz,

Thank you for your question!

> The depot_tools ninja wrapper mentions a restricted bug, https://crbug.com/1340825 

The tracking bug doesn't contain any internal information. So I removed the restriction. 

> the intended solution is for people that need to work with Chromium and also non-DEPS projects

For non-DEPS projects,

I suggest installing ninja in your PATH so that the depot_tools/ninja wrapper can fallback to it.

> old versions of projects from before ninja was put in DEPS

I'm not sure how long people work on old versions. But for chromium branches, I'm requesting cherry-picks of this CL. 

If you work on your fork or branch, please cherry-pick the CL as well.

> Are there any official reasons against having people just run modern ninja locally, ignoring what's in DEPS/depot_tools? 

You can use a new ninja version. It's just not tested by our CI/CQ builders because they use the DEPS ninja. 

Note that I'm going to update the ninja version to 1.11 (https://crbug.com/931218) once I complete this deprecation. 

> I'm worried that having "ninja" resolve to a different version based on CWD will be fragile considering people can do "ninja -C /abs/path", and would like to know what's the downside.

The depot_tools/gn already switches based on CWD to resolve DEPS gn. The depot_tools/ninja follows this pattern. 

The downside of sharing the same ninja is that updating the ninja version will affect all projects without passing CQ. 

I hope my answers help you, but feel free to ask or leave comments on the tracking bug.

Regards,

Junji