cmake: Rework tests target for Coverage configuration and multi-config generators #1592

1. 
   hebasto commented at 3:15 pm on August 18, 2024: member

   When using a multi-config generator, such as “Ninja Multi-Config”, the build system still builds the tests binary for the “Coverage” configuration, which is meaningless:

   0$ cmake -B build -G "Ninja Multi-Config"
   1$ cmake --build build --config Coverage
   2[18/19] Building C object src/CMakeFiles/tests.dir/Coverage/tests.c.o
   3/home/hebasto/git/secp256k1/secp256k1/src/tests.c:18:13: note: ‘#pragma message: Defining VERIFY for tests being built for coverage analysis support is meaningless.’
   4   18 |     #pragma message("Defining VERIFY for tests being built for coverage analysis support is meaningless.")
   5      |             ^~~~~~~
   6[19/19] Linking C executable src/Coverage/tests
   

   This PR fixes the issue.

   It is an alternative to #1251 and #1291.

2. hebasto marked this as a draft on Aug 18, 2024
3. 
   real-or-random commented at 2:55 pm on August 19, 2024: contributor

   @hebasto Can you summarize what this PR does and why is it preferable to #1291? The approach in #1291 seemed natural to me.
4. real-or-random added the label assurance on Aug 1, 2025
5. real-or-random added the label build on Aug 1, 2025
6. real-or-random removed the label assurance on Aug 1, 2025
7. hebasto renamed this:
   cmake: Rework `tests` target for Coverage configuartion and multi-config generators
   cmake: Rework `tests` target for Coverage configuration and multi-config generators
   on Aug 10, 2025
8. cmake: Move `is_multi_config` to unconditional flow

   This change ensures the correct evaluation of `is_multi_config` when
   printing the configure summary.

   d2bd95fd7e
9. cmake: Do not hard-code `CMAKE_CONFIGURATION_TYPES`

   The initial idea was to place the desired default build configuration
   first in `CMAKE_CONFIGURATION_TYPES`. The "Ninja Multi-Config" generator
   treats the first configuration as the default, but this is not the case
   for other generators.
   
   This change uses the dedicated `CMAKE_DEFAULT_BUILD_TYPE` variable for
   the same purpose, avoiding hard-coding `CMAKE_CONFIGURATION_TYPES` and
   preserving users' settings, if any.

   8923d470f2
10. cmake: Allow user to override "Coverage" build type flags 78ef6a73f9
11. cmake: Explicitly specify generators that support Coverage functionality

    Only the "Ninja Multi-Config" generator supports an `EXCLUDE_FROM_ALL`
    target property value that varies by configuration.

    b2119a790f
12. cmake: Rework `tests` target for Coverage and multi-config generators 7d5a19ca88
13. hebasto force-pushed on Aug 10, 2025
14. hebasto marked this as ready for review on Aug 10, 2025
15. 
    hebasto commented at 5:49 pm on August 10, 2025: member

    Rebased and reworked.

    The following is an example workflow on Ubuntu 24.04:

    0cmake -B build -DCMAKE_GENERATOR="Ninja Multi-Config"
    1cmake --build build --config Coverage  # Ninja uses all available cores by default
    2ctest --test-dir build -j $(nproc) -C Coverage
    3mkdir -p build/coverage
    4gcovr --merge-mode-functions=separate --exclude 'src/bench*' --html --html-details -o build/coverage/coverage.html
    5firefox build/coverage/coverage.html
    

16. 
    hebasto commented at 9:49 pm on August 10, 2025: member

    @hebasto Can you summarize what this PR does and why is it preferable to #1291? The approach in #1291 seemed natural to me.

    Answered in #1716 (comment).

Contributors
hebasto real-or-random

Labels
build