CMake allows different approaches for running static analysis tools over a codebase: co-compiling and using a compilation database.
Bitcoin Core uses the latter. This approach has many benefits: for example, the ability to filter entries, which allows us to maintain a list of sources where IWYU warnings are enforced. When processing the compilation database, IWYU expects to find every source and header. This is not the case when the database is generated solely during the configuration step, as it lacks the headers and sources that will be generated during the subsequent build step.
Modern CMake provides a way to generate expected headers and sources beforehand using the built-in codegen target. This approach is currently used in the Bitcoin Core IWYU CI job.
However, the Libmultiprocess project seems inherently incapable of supporting the codegen target. While it is almost trivial to amend add_custom_command in the target_capnp_sources function with the conditional CODEGEN option, doing so is not possible for the capnp_generate_cpp function shipped by libcapnp-dev or similar packages.
There are several ways we could tackle this issue:
-
Execute a normal build step: This guarantees that all files will be generated without relying on codegen at all.
-
Introduce a custom target: We could create a custom target to generate all files beforehand, though this might be challenging.
-
Use CMake's co-compilation: Switch to the co-compiling approach, though I am unsure about the usability of this method for the CI job.
-
Alternative solutions: Open to other ideas.
I am hoping to gather my colleagues' opinions on the best way forward.
CMake allows different approaches for running static analysis tools over a codebase: co-compiling and using a compilation database.
Bitcoin Core uses the latter. This approach has many benefits: for example, the ability to filter entries, which allows us to maintain a list of sources where IWYU warnings are enforced. When processing the compilation database, IWYU expects to find every source and header. This is not the case when the database is generated solely during the configuration step, as it lacks the headers and sources that will be generated during the subsequent build step.
Modern CMake provides a way to generate expected headers and sources beforehand using the built-in
codegentarget. This approach is currently used in the Bitcoin Core IWYU CI job.However, the Libmultiprocess project seems inherently incapable of supporting the
codegentarget. While it is almost trivial to amendadd_custom_commandin thetarget_capnp_sourcesfunction with the conditionalCODEGENoption, doing so is not possible for thecapnp_generate_cppfunction shipped bylibcapnp-devor similar packages.There are several ways we could tackle this issue:
Execute a normal build step: This guarantees that all files will be generated without relying on codegen at all.
Introduce a custom target: We could create a custom target to generate all files beforehand, though this might be challenging.
Use CMake's co-compilation: Switch to the co-compiling approach, though I am unsure about the usability of this method for the CI job.
Alternative solutions: Open to other ideas.
I am hoping to gather my colleagues' opinions on the best way forward.