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

pull purpleKarrot wants to merge 1 commits into bitcoin-core:master from purpleKarrot:ctest-launcher changing 1 files +1 −0
  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:

    CMake Error:
      CTEST_USE_LAUNCHERS is enabled, but the RULE_LAUNCH_COMPILE global property
      is not defined.
    
      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.

    #!/usr/bin/env -S ctest -VV -S
    
    set(CTEST_SOURCE_DIRECTORY "/path/to/secp256k1")
    set(CTEST_BINARY_DIRECTORY "/path/to/secp256k1-build")
    
    set(CTEST_CMAKE_GENERATOR "Ninja")
    set(CTEST_USE_LAUNCHERS ON)
    
    ctest_empty_binary_directory(${CTEST_BINARY_DIRECTORY})
    ctest_start("Experimental")
    ctest_configure()
    ctest_build()
    
  2. real-or-random added the label build on Jun 19, 2025
  3. in CMakeLists.txt:16 in 8e759c8fb0 outdated
      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?

    include(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.

  4. real-or-random commented at 1:07 PM on June 19, 2025: contributor
  5. real-or-random added the label feature on Jun 23, 2025
  6. 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!

  7. 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.

  8. cmake: support the use of launchers in ctest -S scripts 0dfe387dbe
  9. purpleKarrot force-pushed on Jun 30, 2025
  10. hebasto approved
  11. hebasto commented at 11:07 AM on June 30, 2025: member

    ACK 0dfe387dbe345d92d12b3de5c41a685fb6654211.

  12. real-or-random merged this on Jul 1, 2025
  13. real-or-random closed this on Jul 1, 2025

  14. purpleKarrot deleted the branch on Jul 1, 2025
  15. Sjors referenced this in commit 1b7453ea88 on Jul 17, 2025
  16. hebasto referenced this in commit 28310efba4 on Jul 18, 2025
  17. fanquake referenced this in commit 5600e6fc4b on Jul 22, 2025
  18. fjahr referenced this in commit b6fc8c52d5 on Jul 24, 2025
  19. saikiran57 referenced this in commit abe11bd67c on Jul 28, 2025
  20. janus referenced this in commit e0ffd31e87 on Sep 14, 2025
  21. vmta referenced this in commit 2b25f561a0 on Sep 21, 2025
  22. real-or-random referenced this in commit a3733f33c1 on Feb 25, 2026
  23. github-actions[bot] referenced this in commit 758d4e90b4 on Mar 1, 2026
  24. github-actions[bot] referenced this in commit 68a2178f22 on Mar 1, 2026
  25. github-actions[bot] referenced this in commit a8bc1a0b2b on Mar 1, 2026
  26. 0x000000000019d6689c085ae165831e934ff76 referenced this in commit 3b9450150d on Mar 2, 2026
  27. csjones referenced this in commit a4d92824ae on Mar 2, 2026

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin-core/secp256k1. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-05-19 06:52 UTC