vmr ninja build dependency

[tmds]

dotnet/runtime#124041 added the use of ninja to speed up the runtime builds.

This speeds up the runtime build by 10-15 seconds on Linux. The runtime build script expects ninja to be available by default and ninja was added to the Dockerfiles that are used in GitHub CI.

For vmr build:

• should the dependency be documented somewhere?
• should there be a flag to to enable/disable ninja on the top-level build.sh?
• what should be the default behavior?
• are there CI builds that build using the non-default behavior (to verify it works)?

@steveisok @jkotas @jkoritzinsky @am11 @dotnet/source-build @omajid

[steveisok]

The build time boost was more than 10-15 seconds. It was between 5-12% depending on where you ran it.

[tmds]

@am11 shared his vmr cross builds for riscv64 to be reduced by about 10-15s on a 60-70min build.

I assume the 5-12% improvement is for runtime (or a subset of runtime) and not for the entire vmr build.

On a vmr build (where native runtime only makes up a very small part of the build time), the speedup is 0.4% ish.

[am11]

should the dependency be documented somewhere?

Yes, both places where other build dependencies are tracked were updated:

• https://github.com/dotnet/runtime/blob/93d49/docs/workflow/requirements/linux-requirements.md
• https://github.com/dotnet/runtime/blob/93d49/eng/common/native/install-dependencies.sh

are there CI builds that build using the non-default behavior (to verify it works)?

Not currently. dotnet/runtime#124562 was discovered manually about two weeks after dotnet/runtime#124041.

It might make sense to add a CI leg that exercises non-default configurations more broadly. I am not sure the non-ninja path needs a dedicated leg specifically, aside from being new, but having at least one configuration covering non-default build options would help catch this class of issues earlier.

should there be a flag to enable/disable ninja on the top-level build.sh?

Stepping back from the ninja vs. make choice itself, it would be useful to have a clearer and more streamlined way for distro maintainers to stay in sync with evolving build dependencies. dotnet/runtime is a busy repo with 50–100 PRs per week, so dependency changes are inevitable.

The ninja vs. make aspect is probably something we can live with as-is (on by default), though I am open to adding a flag if it meaningfully improves maintainability or downstream packaging workflows.

[omajid]

As a downstream maintainer, I prefer to avoid taking additional dependencies where possible. make is more likely to be available on platforms and environments, so I would prefer to stick to that.

[tmds]

@steveisok it's not clear why vmr build.sh should change to use ninja by default. I don't think we "must" align with runtime build.sh. These build scripts serve different use-cases, so they can have different defaults.

[jkotas]

it's not clear why vmr build.sh should change to use ninja by default

We depend on vmr and dotnet/runtime CI to produce same bits. We do most of our validation on bits produced by dotnet/runtime CI and ship bits produced by vmr.

Using different build systems for vmr and dotnet/runtime increases chances of vmr-specific issues that we do not catch in our validation.

[tmds]

I see. Using ninja for all upstream CI and validation is intentional.

Which also makes it the recommended build system for distro maintainers.

And vmr build.sh default expresses this.

[tmds]

Questions are answered. Closing.