Guardrails / cpp

Dependencies come from a package manager

cpp/package-manager-declared@v1

The checkout declares its dependencies through vcpkg or Conan, so it names the versions it builds against rather than taking whatever the machine carries.

Id	cpp/package-manager-declared
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/package-manager-declared@v1",
              "severity": "warning",
              "with": {
                  "projectDir": "."
              },
              "exemptions": []
          }
      ]
  }
}

Inputs

Input	Description	Default	Environment variable
projectDir	Directory holding the project, relative to the directory the CLI runs in.	.	GUARDRAIL_INPUT_PROJECTDIR

How to fix

Declare the dependencies in a manifest the build resolves from, rather than leaving find_package to find whatever is installed. A vcpkg.json beside CMakeLists.txt:

{
  "name": "widget",
  "version": "1.2.3",
  "builtin-baseline": "6f3a1c2d9b8e4f7a0c5d2e1b3a4f5c6d7e8f9a0b",
  "dependencies": ["fmt", { "name": "spdlog", "version>=": "1.13.0" }]
}

or a conanfile.txt naming fmt/10.2.1 under [requires]. Without one, the versions a build links against are the system packages the machine happens to carry, so the same commit builds against a different fmt on a laptop, on CI and in the release image, and the difference shows up as a crash rather than as a resolution error.

More in cpp

• cpp/cmake-minimum-floor. A CMake build names the CMake version whose policy defaults it configures under, and that version is no older than the configured floor.
• 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.

All 4 cpp guardrails