Ensure binary is created before add_test is run

Code
1

I am trying to run individual tests for Boost in CMake.
a Boost test binary can be run with --list_content option to list down all the tests inside the executable.
I am using this list with CMake’s add_test option to add individual tests. However, the problem is when I build all(ie run the root CMake script), it tries to run add_test before the Boost test binary is even compiled, due to which the above --list_content command fails, and no tests get added to ctest. For eg:

add_executable(end_to_end_test tests/end_to_end_test.cpp)
target_link_libraries(end_to_end_test Dep1 Dep2 )
add_boost_test_fn(end_to_end_test) # this function runs the above end_to_end_test binary with --list_content option and adds individual tests

Here, add_boost_test_fn(which runs add_test internally) seems to be running before end_to_end_test executable is even generated.
By contrast, if this binary already exists, and then the root CMake script is run, these tests get added fine.
How can it be ensured that add_test is run for a binary only after the binary is compiled and generated in its correct location ?

2

It sounds like something like the GTest mechanism should be implemented for Boost.Test. This defers listing the tests until ctest time (AFAIK).

Cc: @Matthew_Woehlke @pdimov

3

Hi, what is the GTest mechanism ?
I want a prerequisite, or a dependency for the add_boost_test_fn function, so that I can say that the function (which internally runs the above binary in execute_process command) is run after the test binary is built first.

4

I see there’s also a problem with execute_process, since it runs prior to system generation. I need to run add_custom_target/command for the above purpose instead…

5

Correct. Prior to add_test is impossible (because it happens during configure). I believe the GTest mechanism is to defer test detection until test time so that the tests are discovered at that point. But those that I Cc’d probably know better.

6

I would recommend reading through GoogleTest.cmake. There are actually two modes; build-time discovery (more efficient; only needs to run if the test changes) and test-time discovery (tends to work better if the test needs environmental setup, e.g. especially on cross-compiles). The general idea, however, is that something post-configure generates the add_test commands into something that is invoked by a script that is added to TEST_INCLUDE_FILES. (The additional level of indirection is so the ‘first’ script, which is guaranteed to exist, can check if the test executable or generated test list exists and produce more useful diagnostics in case of a failure.) The wrapper (gtest_discover_tests) handles setting all this up; users never call add_test directly.

In fact, I would recommend copying from GoogleTest.cmake as much as possible, as there is a bunch of corner-case handling that you probably don’t want to have to reinvent or rediscover.