[CMake] building tests

[Michael Wild]

[snip]

>> 
>> Ok first thing: I had two cmakes on my system, one was 2.8.1, and an older
>> 2.6.3 that snuck in through an incorrect script of mine.
>> 
>> Second thing: the TARGET_FILE thing works.  But the usual add_test(name
>> command) does not.
> 
> This is because you set the CMAKE_RUNTIME_OUTPUT_DIRECTORY to a location
> CMake does not take into account with ADD_TEST(<test> <exec>), but - as
> MW already pointed out - ADD_TEST(NAME <test> COMMAND <target>) works
> since this command resolves the executable's path for the target by
> itself as $<TARGET_FILE:...> does, too.
> 
> Typically, ADD_TEST(<test> <exec>) would be used if the test driver is
> an external tool, i.e. not part of your project, and located, e.g., by
> FIND_PROGRAM(). Nevertheless, CMake looks for it at several familiar
> places in case it's still built by the project. The recent signature
> ADD_TEST(NAME <test> COMMAND <target>) is used if the test driver is
> actually built by the project, and $<TARGET_FILE:...> et al. address
> the difficulty to predict the location of binaries during the CMake
> run when configuring for multi-configuration capable build systems.
> 
> In short: Take "add_test(NAME unit_1 COMMAND unit_1)" for Makefiles or
> "add_test(NAME unit_1 COMMAND $<TARGET_FILE:unit_1>)" to be bulletproof.
> 
> Regards,
> 
> Michael

Actually, add_test(NAME unit_1 COMMAND unit_1) should always work, even for multi-config IDE's. The $<...> expansion exists if you need to pass the location of the executable as an argument to some driver-script instead of executing it directly. This is often the case for test programs that require environment variables to be set to a specific value or require some special input files to be copied from somewhere, so you create a wrapper script which sets up things and only then executes the test program.

Michael