On 18/09/18 20:58, Zach Laine via Boost wrote:
On Tue, Sep 18, 2018 at 2:53 PM Roger Leigh via Boost
wrote: On 18/09/18 17:47, Peter Dimov via Boost wrote:
How would this interact with enable_testing() and add_test()?
Since "check" is a non-standard target added by individual components, it shouldn't interact with enable_testing() and add_test() at all as far as I can see. (If the dependencies of the check target aren't built by default (ALL) and are also used by add_test() then that might be a potential problem, but I'd then question what the "check" target was really for in the first placeā¦ since testing is usually done by running ctest and not building a target.)
It exists because many, many users are used to building a library in these steps:
./configure make make check make install
And with a check target, you get something eerily similar:
cmake .. make make check make install
CMake already provides two mechanisms for running tests: 1) ctest (the recommended way) 2) "make test" (when using the "Unix Makefiles" generator) Doing it a third way which is non-standard for CMake is the least useful choice. I agree it's superficially compatible with the Automake check/check-TESTS targets and it does have developer familiarity. However, while common it is tool-specific and it's not necessarily great for getting people familiar with the best practices when using CMake. Using ctest directly is vastly more flexible (none of its options are exposed via the target). It would be nice if you could alias "check" to "test" with add_custom_target(check DEPENDS test) but the test target is only emitted in the Makefile as boilerplate; it never exists internally as a CMake target. # Special rule for the target test test: @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --cyan "Running tests..." /usr/bin/ctest --force-new-ctest-process $(ARGS) .PHONY : test You can set ARGS to pass options, but that's it. It's still generator-specific and non-standard. A custom check target doesn't even allow the flexibility of passing different options at runtime. Regards, Roger