[cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test?

Clifford Yapp cliffyapp at gmail.com
Mon Oct 3 12:14:29 EDT 2016


On Mon, Oct 3, 2016 at 11:21 AM, Brad King <brad.king at kitware.com> wrote:
> On 10/03/2016 11:17 AM, Clifford Yapp wrote:
>> One of the functions we are wrapping in our build with CMake's "_"
>> prefix debugging mechanism is add_test.  Looking at why we do that, it
>> should be possible to avoid wrapping if we can get access in CMake to
>> the list of all test build targets defined with add_test.
>> Essentially, we need to add them to some custom target dependencies,
>> and it should be OK to do that after all tests are added if we can get
>> access to the list of targets within CMake.
>>
>> Is there a property somewhere that exposes this list?
>
> I don't recall one off the top of my head.  Even if there were,
> the `set_property(TEST ...)` only works on tests in the invoking
> directory.  There is no global scope for test names.

Hmm.  OK, so what we need is not actually the test names themselves,
but a list of the executables used to run tests that are also defined
as build targets.  So, for example, we have a test that is named
bu_basename_usr that runs the executable test_bu_basename.  What we
actually need is for the build target test_bu_basename to be a
dependency of the custom target "check".  Then, when the custom target
"check" executes, it will first make sure all of the text executables
(and their dependencies) have  been built.

The list we need would thus be built up to contain all COMMAND
arguments to add_test that are also build targets in CMake.  Does that
make sense?

> Some projects use a `myproj_add_test()` wrapper around their
> `add_test()` calls specifically to provide customizations.

I suspect that would run into issues similar to those we're seeing now
trying to pass empty strings from the wrapper to the children, unless
perhaps a macro wrapper would work where a function wrapper would
not...:  https://gitlab.kitware.com/cmake/cmake/issues/16341

Cheers,
CY


More information about the cmake-developers mailing list