CMake floor is recent enough
cpp/cmake-minimum-floor@v1
A CMake build names the CMake version whose policy defaults it configures under, and that version is no older than the configured floor.
| Id | cpp/cmake-minimum-floor |
| Version | v1 |
| Category | cpp |
| Default severity | warning |
| Interpreter | python3 |
| Timeout | 30 seconds |
| Violations tolerated | 0 |
| Collects | cpp |
Collectors
This guardrail gathers nothing itself. It depends on the collectors below, which the CLI runs once per build before any check, and reads what they found out of GUARDRAIL_FACTS. A collector that collects nothing skips this guardrail rather than failing it.
| Collector | Gathers | Inputs it is given |
|---|---|---|
cpp | The C or C++ build in the project directory: which build system and package manager it uses, the C++ standard and CMake version it requires, the packages it declares and which of them are pinned, and the packages it expects the machine to carry. CMakeLists.txt is a script, so what it declares conditionally is not seen and scanned says so. | projectDir |
The inputs above are this guardrail's own, passed straight through. Configuring one in buildnote.json changes what is collected, and two guardrails configured the same way share the one collection.
Configuration
{
"guardrails": {
"failOn": "error",
"comment": true,
"checks": [
{
"use": "cpp/cmake-minimum-floor@v1",
"severity": "warning",
"with": {
"projectDir": ".",
"minVersion": "3.20"
},
"exemptions": []
}
]
}
}Inputs
| Input | Description | Default | Environment variable |
|---|---|---|---|
projectDir | Directory holding the project, relative to the directory the CLI runs in. | . | GUARDRAIL_INPUT_PROJECTDIR |
minVersion | Oldest CMake version accepted in cmake_minimum_required, compared against the policy version it selects. A version below this is a violation. | 3.20 | GUARDRAIL_INPUT_MINVERSION |
How to fix
Raise the floor on the first line of CMakeLists.txt:
cmake_minimum_required(VERSION 3.25)The floor is what selects CMake's policy defaults, so an old one quietly keeps old behaviour for target properties, find_package search order and RPATH handling, and a build that reads as modern is configured under rules from a decade ago. Below 3.5 current CMake refuses to configure at all, and with no cmake_minimum_required the policies are whichever ones the installed CMake defaults to. In the range form cmake_minimum_required(VERSION 3.10...3.28) the upper bound is what selects the policies, so that is the version compared with the floor.
More in cpp
cpp/package-manager-declared. The checkout declares its dependencies through vcpkg or Conan, so it names the versions it builds against rather than taking whatever the machine carries.cpp/standard-declared. A CMake build that enables C++ declares the standard it compiles against, and that standard is no older than the configured floor.cpp/standard-required. A CMake build that enables C++ requires the standard it declares, so a compiler that does not offer it fails rather than falling back to an older one.