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

[purpleKarrot]

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()

[real-or-random]

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

[purpleKarrot]

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]

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?

Suggested change

	include(CTestUseLaunchers)
	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]

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

I agree.

[real-or-random]

cc @hebasto

[hebasto]

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!

[hebasto]

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

I agree.

[real-or-random]

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.