Boost logo

Boost :

Subject: Re: [boost] [cmake] Pull request announcement
From: Roger Leigh (rleigh_at_[hidden])
Date: 2018-09-18 20:43:50


On 18/09/18 20:58, Zach Laine via Boost wrote:
> On Tue, Sep 18, 2018 at 2:53 PM Roger Leigh via Boost <boost_at_[hidden]>
> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk