F43 Change Proposal: CMake: Use ninja generator by default (system-wide)

Project Discussion Change Proposals
,
1

CMake: Use ninja generator by default

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Change the default generator used in the %cmake macro from make to ninja. Affected projects are tracked in this copr repo, please check if your packages are failing there.

:link: Owner

:link: Detailed Description

ninja is generally regarded as a faster build backend/generator than make, and recently CMake features support the ninja backend better. Various packages already define and use the ninja backend manually, and this change proposal would change the build backend to all of the other packages that use the %cmake macro.

Indirect callers to cmake such as when part of python package, would be unaffected and they could implement an equivalent change independently.

:link: Migration

Compatibility with fedora releases
Any proposed changes here are compatible with any CMake versions and can be included at any point and backported to any Fedora release.
The corresponding cmake PR will not be merged until the affected packages are patched.

  • Make sure you do not use any %make_install and equivalent in the spec file. Instead use the generator agnostic macros %cmake_build, %cmake_install, etc.
  • If you need to opt-out of the ninja generator add the following line in the specfile before the %cmake execution

%global cmake_generator make

:link: Benefit to Fedora

  • Faster build system
  • Better out-of-the-box support for newer CMake features such as C++ module support

:link: Scope

  • Proposal owners:

    • Make the ninja build backend be the default
    • Try to propose appropriate fixes as much as possible
    • Investigate the edge-cases that are not covered in Migration

  • Other developers:

    • Adjust the spec file at least with the minimum quick fix. See Migration.

  • Release engineering: #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

:link: Upgrade/compatibility impact

Affected packages would be FTBFS (in the tracked copr repo) and would require patching before the corresponding cmake PR can be merged.

:link: How To Test

A copr repo will be provided with these variables dropped. Use it to try local builds, e.g. using:

copr mock-config lecris/cmake-drop_vars fedora-rawhide-x86_64

If the build is successful, that should be sufficient.

:link: Dependencies

There are currently 310/2359 packages affected gathered and built using mass-pre-build in copr, many of them are previously FTBFS in rawhide.

:link: Contingency Plan

  • Contingency mechanism: N/A (no deadline set)
  • Contingency deadline: No deadline necessary yet
  • Blocks release? No

:link: Documentation

:link: Release Notes

Last edited by @amoloney 2025-04-16T12:09:57Z

Last edited by @amoloney 2025-04-16T12:09:57Z

1 Like
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

This seems to be the wrong change? Either the title or the document needs to be updated.

4

You are too quick :sweat_smile: I copy-pasted the wrong wiki, I still had the previous one open. Should be all correct now.

5

I think that the motivation is reasonable, and that this change will be beneficial to Fedora overall as long as it’s implemented carefully.

Speaking from my own experience, the ninja backend almost always builds projects with more than a handful of source files measurably faster (benchmarking at the very highest level, time fedpkg mockbuild is consistently quicker). Projects that don’t work with ninja for one reason or another seem to be extremely rare, and it’s reasonable to expect them to be handled as exceptions rather than allowing them to determine the default.

1 Like