Skip to content

Tracking: Build Failures with CMake 4 #445447

New issue
New issue
Open
85 of 86 issues completed
#452562
Open
Tracking: Build Failures with CMake 4#445447
85 of 86 issues completed
#452562
Assignees
Sigmanificient
Labels
0.kind: build failureA package fails to build3.skill: good-first-bugThis seems like it's fixable by a non-expert3.skill: sprintableA larger issue which is split into distinct actionable tasks5.scope: trackingLong-lived issue tracking long-term fixes or multiple sub-problems
@LordGrimmauld

Description

@LordGrimmauld
LordGrimmauld
opened on Sep 23, 2025

What broke?

@biodranik and @emilazy did an amazing job updating our cmake. This update was long overdue, and it finally happened. But as is common with these updates on build systems, a lot of dependents broke. This tracking issue is intended to track current failures as well as ongoing fix PRs.

How to find broken packages

I plan to grep through hydra logs. In the meantime, you can look at the current staging-next on https://malob.github.io/nix-review-tools-reports/ and find fails with Compatibility with CMake < 3.5 has been removed from CMake. (e.g. gl2ps, tlsh). If anyone else already has a a tool to search through hydra logs for a specific string, help here would be appreciated.

How to fix broken packages

CMakeLists.txt should contain a minimum version definition:

cmake_minimum_required(VERSION 3.10)

Versions older than <3.5 are unsupported by cmake 4. Versions between 3.5<=version<3.10 are deprecated and will lose support in a bit. The goal is to bump cmake compat version to at least 3.10+ so we won't have the same issues in half a year again.
If you are authoring patches, prefer bumping straight to 3.10.

  1. Check for updates. Upstream might already have published a version with the cmake version increased to 3.10+. In this case, just open a regular update pull request.
  2. Check for upstream commits. They may have added the cmake bump but not made a release. In this case, either update to an -unstable version, or fetchpatch the commit. Don't forget to add ?full_index=1 to github patch fetching. In case where upstream adjusted their github actions files, it may make sense to use fetchpatch2 { url = ...; hash = ...; includes = [ "CMakeLists.txt" ];} to avoid merge conflicts with ci files (such as gh actions, see e.g. https://github.com/NixOS/nixpkgs/pull/445295/files)
  3. Check upstream PRs. If these are not yet merged, download the patch and vendor it within nixpkgs. Add a comment where you got the patch from.
  4. If upstream is generally responsive and active, write a patch and open a PR upstream. Then go back to option 3.
  5. Check other package repositories. Gentoo already did the cmake 4 update before we did. They have a lot of cmake 4 compat patches which we can fetch instead of authoring them.
  6. Write your own patch (or substituteInPlace) within nixpkgs
  7. (Only if there is multiple package variants): If cmake 4 compat exists with some variants and not others, overriding by cmake flag may make sense, e.g.:

    nixpkgs/pkgs/servers/sql/mariadb/default.nix

    Lines 313 to 316 in 589e4d0

    ++ lib.optionals (lib.versionOlder version "11.4") [
    # Fix the build with CMake 4.
    "-DCMAKE_POLICY_VERSION_MINIMUM=3.5"
    ]
    (though 3.10 would be preferable over 3.5)

Failures / Fixes

Sub-issues

Metadata

Metadata

Assignees

Labels

0.kind: build failureA package fails to build3.skill: good-first-bugThis seems like it's fixable by a non-expert3.skill: sprintableA larger issue which is split into distinct actionable tasks5.scope: trackingLong-lived issue tracking long-term fixes or multiple sub-problems

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions