cmake

Overview

CMake is a build-system generator used to configure and generate build files for software projects. Upstream describes it as a tool for managing source builds and generating buildsystems such as Ninja or IDE project files. It is widely used for C and C++ projects, and can also be used for other languages when a project adopts CMake-based build logic. (cmake.org)

In a Linux distribution, the cmake package usually provides the command-line tools and modules that other packages need at build time. It is commonly required by maintainers, developers, and CI/CD jobs that configure or rebuild software with CMake-based build files. NiceOS maintainers should verify the exact packaging split in this repository before relying on any specific subpackage behavior.

Purpose and typical use cases

Typical use cases include:

• configuring upstream source trees that use CMakeLists.txt
• generating Unix Makefiles, Ninja build files, or IDE project files
• driving out-of-tree builds for development and packaging work
• building projects in CI pipelines that expect a standard CMake interface
• using CMake modules and helper commands from packaged software that depends on CMake at build time

Typical users include:

• package maintainers who rebuild upstream software
• application developers working on C, C++, and mixed-language projects
• CI/CD maintainers who need reproducible configuration steps
• build and release engineers who package software for multiple targets
• desktop or workstation users who build software from source

Upstream project

The upstream project is CMake from Kitware. The canonical project website is cmake.org, and the official documentation states that CMake manages source builds and generates buildsystems such as Ninja and IDE project files. The official upstream repository is maintained by Kitware; NiceOS maintainers should verify the preferred upstream Git remote for updates if they need to mirror or audit source changes. (cmake.org)

Dist-git repository contents

This dist-git repository is structured as follows:

• SPECS/ — RPM spec files and packaging logic.
• SOURCES/ — source metadata and manifest files used to track what should be fetched for the build.
• METADATA/ — repository metadata used by the packaging workflow.
• SBOM/ — software bill of materials data, when present in the package workflow.

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source-integrity metadata in SOURCES/ manifests so that the build system can fetch the upstream source and verify that the expected content is being used.

Source storage and integrity policy

For this package, source integrity is tracked through manifest files under SOURCES/. The intent is to keep the Git history small and stable while still recording which upstream source artifacts belong to the package.

Maintainers should treat any change in the source manifest as a point where upstream content needs to be rechecked. Do not assume that the packaged source is correct just because the spec file still builds; verify the fetched upstream source, the manifest update, and the resulting build inputs together.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether the upstream release changes the build requirements or supported generators
• whether the spec file needs new patches, refreshed macros, or updated build flags
• whether any files in SOURCES/ must be regenerated or replaced
• whether the SBOM data, if used, needs to be refreshed
• whether packaging changes affect dependent packages that use cmake during their own builds
• whether the update changes command-line behavior that downstream scripts may rely on

Practical risks to consider:

• build systems can break if upstream CMake changes defaults or removes old compatibility paths
• packaging scripts may rely on module locations or helper behavior that should be revalidated after an update
• downstream build recipes may need adjustments when CMake emits different diagnostics or enforces stricter checks

Build and verification checklist

Suggested checklist for RPM maintainers:

• review the spec file for versioned source references and packaging macros
• confirm that SOURCES/ manifests point to the intended upstream content
• verify that any generated files are updated consistently, including SBOM/ if it is part of the workflow
• run a clean RPM build in a controlled environment
• check that the installed binaries, modules, and documentation land in the expected subpackages
• validate that the package still satisfies dependent build tooling
• perform at least one test build of a package that uses CMake, if available in the repository set
• inspect build logs for changed warnings, missing modules, or altered defaults

References

• CMake official website
• CMake reference documentation
• CMake upstream repository

Russian documentation

See README_RU.md for the Russian version of this document.

Dist-git repository notes

• Package repository: rpms/cmake
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.