Guard cppcheck dependency on target existence#510
Conversation
The `cppcheck` target is only created when CppcheckConfig.cmake finds the cppcheck binary. The unconditional `add_dependencies(cppcheck ...)` breaks CMake configure on systems without cppcheck installed (CI containers, Conan builds, minimal dev setups). Wrap the call in `if(TARGET cppcheck)` so the build works regardless. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
f9463d3 to
f630cd4
Compare
|
@r1viollet @nsavoire This is the first PR of 5 PRs to make the build more friendly towards packagers such as Conan. Let me know if this out-of-scope for you (we could keep the patches outside) |
|
@xroche thanks for reaching out. I think a lot of these are fine. Please note that we are progressively reducing efforts on |
Thanks for the hint! We have two concerns though:
For now we haven't been able to use ddprof reliably though (due to issues crashing on production); but the traces seems to be doing exactly what we want for CPU and memory |
|
Yes, it is CPU only. We will be working on bringing the memory story to OTel. |
We also have concerns regarding symbolization: we host private binaries and libraries on pods, with dbgsym packages installed for resolving the addresses. The dbgsym size is approximately 4GB for all services. If the symbolization of OTel is done on a backend, does it mean we need to push 4GB of debugging info remotely each time we deploy (that is several times a day) ? |
2 participants
Summary
CMake configure fails on systems without cppcheck installed because
add_dependencies(cppcheck DDProf::Parser)references a target that only exists whenfind_programfinds the cppcheck binary. This breaks CI containers, Conan builds, and minimal dev setups.CMake's
if(TARGET)is the recommended guard for conditionally-created targets.How
Wrap the
add_dependenciescall inif(TARGET cppcheck). No behavior change when cppcheck is installed.🤖 Generated with Claude Code