cmake: support the use of launchers in ctest -S scripts #1687

1. 
   purpleKarrot commented at 10:48 am on June 19, 2025: contributor

   When CTEST_USE_LAUNCHERS is set to ON in a ctest -S script, the configure step fails with the error message:

   0CMake Error:
   1  CTEST_USE_LAUNCHERS is enabled, but the RULE_LAUNCH_COMPILE global property
   2  is not defined.
   3
   4  Did you forget to include(CTest) in the toplevel CMakeLists.txt ?
   

   However, include(CTest) produces unwanted clutter. include(CTestUseLaunchers) is a more lightweight alternative.

   To reproduce the issue, run the following script with and without the PR applied.

    0#!/usr/bin/env -S ctest -VV -S
    1
    2set(CTEST_SOURCE_DIRECTORY "/path/to/secp256k1")
    3set(CTEST_BINARY_DIRECTORY "/path/to/secp256k1-build")
    4
    5set(CTEST_CMAKE_GENERATOR "Ninja")
    6set(CTEST_USE_LAUNCHERS ON)
    7
    8ctest_empty_binary_directory(${CTEST_BINARY_DIRECTORY})
    9ctest_start("Experimental")
   10ctest_configure()
   11ctest_build()
   

2. cmake: support the use of launchers in ctest -S scripts 8e759c8fb0
3. real-or-random added the label build on Jun 19, 2025
4. in CMakeLists.txt:16 in 8e759c8fb0

   12@@ -13,6 +13,7 @@ project(libsecp256k1
   13   LANGUAGES C
   14 )
   15 enable_testing()
   16+include(CTestUseLaunchers)
   

   ---

   ---

   

   real-or-random commented at 1:06 pm on June 19, 2025:

   I think this deserves a comment. Otherwise, it looks like an unused import.

   ---

   

   purpleKarrot commented at 4:08 pm on June 23, 2025:

   I find it hard to come up with a comment that is not stating the obvious. The CTestUseLaunchers module has a single purpose, explained in its documentation.

   ---

   

   real-or-random commented at 8:12 pm on June 23, 2025:

   I find it hard to come up with a comment that is not stating the obvious. The CTestUseLaunchers module has a single purpose, explained in its documentation.

   Okay, I tend to think what is obvious or not is in the eye of the beholder. I assume it’s not obvious for the typical reader.

   What about?

   0include(CTestUseLaunchers)  # for "ctest -S" scripts of the user
   

   The crucial part here is “of the user”. This line is not needed for anything we currently have in our repo.

   ---

   

   hebasto commented at 12:44 pm on June 27, 2025:

   The crucial part here is “of the user”. This line is not needed for anything we currently have in our repo.

   I agree.

5. 
   real-or-random commented at 1:07 pm on June 19, 2025: contributor

   cc @hebasto
6. real-or-random added the label feature on Jun 23, 2025
7. 
   hebasto commented at 12:45 pm on June 27, 2025: member

   Concept ACK.

   This PR is about integrating ctest with CDash—a web-based dashboard that collects results from a software build and test pipeline driven by ctest. It collects warnings and errors from each stage of the pipeline, and shows per-stage summaries with the ability to click through to each warning or error.

   I’ve created a dashboard for this project for testing and demonstration purposes.

   The dashboard accepts submissions from anyone, potentially broadening test coverage with environments defined by other developers.

   This PR raises a few questions:

   1. Do we want to adopt CDash as part of the project’s testing framework going forward?

   2. If so, what would the timeline look like (e.g., initial experimentation, migrating all CI jobs to CMake, etc.)?

   Regarding this PR specifically, it’s important to note that CDash can be used by other developers regardless of whether there is an “official” project dashboard.

   Therefore, this change can be immediately beneficial.

   In particular, set(CTEST_USE_LAUNCHERS YES) improves CDash logs by exposing the command lines used during the build. See an example here.

   UPD. Many thanks to @purpleKarrot for the helpful offline discussions regarding this topic!

8. 
   real-or-random commented at 6:34 pm on June 27, 2025: contributor

   This PR is about integrating ctest with CDash—a web-based dashboard that collects results from a software build and test pipeline driven by ctest. It collects warnings and errors from each stage of the pipeline, and shows per-stage summaries with the ability to click through to each warning or error.

   I’ve created a dashboard for this project for testing and demonstration purposes.

   I had no idea. This looks useful indeed, if only to browse our CI builds better.

Contributors
purpleKarrot real-or-random hebasto

Labels
feature build