Config Contract Enforcement

When introducing or updating environment/configuration behavior, ensure the documented meaning, runtime inputs (CLI/feature flags), and build-time discovery (CMake/pkg paths) all point to the same intended target. Avoid “it compiles” success that doesn’t enable the feature, and avoid “it builds” that accidentally links against a mismatched dependency set.

copy reviewer prompt

Prompt

Reviewer Prompt
Deploy Agent

When introducing or updating environment/configuration behavior, ensure the documented meaning, runtime inputs (CLI/feature flags), and build-time discovery (CMake/pkg paths) all point to the same intended target. Avoid “it compiles” success that doesn’t enable the feature, and avoid “it builds” that accidentally links against a mismatched dependency set.

Apply this checklist: 1) Runtime flags must match documentation semantics

  • If a config value means “disabled” (e.g., gpu_device = -1), do not report results or behavior as if the feature were enabled. Ensure the corresponding benchmark/runtime command-line option actually enables it.

2) Build-time dependency resolution must be anchored to an explicit prefix

  • Install dependencies to a dedicated directory via --prefix.
  • In CMake, set CMAKE_PREFIX_PATH to paths under that prefix (so bin/lib/include match) BEFORE find_package.

Example (CMake prefix configuration):

# e.g., /path/to/protobuf/install
set(ProtobufRoot "/path/to/protobuf/install")

# Point CMake to the exact install root’s artifacts
list(APPEND CMAKE_PREFIX_PATH
     "${ProtobufRoot}/bin"
     "${ProtobufRoot}/lib"
     "${ProtobufRoot}/include")

find_package(Protobuf REQUIRED)

If configuration involves both build and runtime, verify end-to-end: the build-time selection (what got found/linked) and the runtime enablement (what got switched on) are consistent with the docs and expected behavior.

Source discussions