Open MTomBosch opened 1 year ago
hi @MTomBosch
Yes, that is more or less the process:
conan install . -o coverage=True
will generate something in the conan_toolchain.cmake
or CMakePresets.json
, depending on the mapping you do in generate()
method to the CMakeToolchain
classconan build
, but just calling CMake with the right generated filelayout()
. The default cmake_layout()
with tools.cmake.cmake_layout:build_folder_vars = ["options.coverage", ....]
can create those different folders.
What is your question?
We need to build a package containing some binaries in two variants, once the normal binary and once the binaries must be instrumented so that the code coverage can be measured after tests have run. For building we are using cmake that is invoked via the conan recipe build() function.
What I am thinking about is to introduce an option "coverage" to the conan package that allows to differentiate the variants of the package. Since this option is transported to the CMake call as a variable the cmakelist file can be implemented to either create instrumented or non-instrumented binary code depending on the option value.
Now the question would be how and when this option needs to be set. In case I first want to build the non-instrumented binary I of course run a conan install and then a conan build. If I now want to build the instrumented variant how can I hand over the "coverage" option to the build command assuming that the dependincies are the same for both variants? I guess I have to run a conan install with the option "coverage=true" so that this option is saved locally for the build function, right?
Last and most important question: What I described above, does that make sense or is there a better approach?
Thank you
Have you read the CONTRIBUTING guide?