Re: [boost] CMake and Boost Build tests

Subject: Re: [boost] CMake and Boost Build tests
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-07-27 02:48:08

On 7/26/2017 3:42 PM, paul via Boost wrote:
> On Wed, 2017-07-26 at 14:49 -0400, Edward Diener via Boost wrote:
>> Following John Maddock's appeal for practical solutions related to the
>> move to CMake, I would like to know what the CMake equivalent is to the
>> Boost Build unit test functionality.
>>
>> In other words what do I write for CMake in order to do a Boost Build
>> compile, compile-fail, link, link-fail, run, and run-fail unit tests ?
> 
> For a run test, you would do, something like:
> 
> add_executable(footest footest.cpp)
> add_test(NAME footest COMMAND $<TARGET_FILE:footest>)

OK, that makes sense.

> 
> For a compile/link test:
> 
> add_library(footest STATIC EXCLUDE_FROM_ALL footest.cpp)
> add_test(NAME footest COMMAND ${CMAKE_COMMAND} --build . --target footest --
> config $<CONFIGURATION> WORKING_DIRECTORY ${CMAKE_BINARY_DIR})

Why am I adding a library when all I am trying to do is see whether 
source file(s) can be compiled to their object files successfully ( the 
compile test ) or whether source file(s) can be compiled to their object 
files successfully then linked as an executable without linking errors ( 
the link test ) ?

> 
> To make the tests with expected failures, just set a property:
> 
> set_tests_properties(footest PROPERTIES WILL_FAIL TRUE)

OK, thanks !

> 
> You also can check for certain output, which nice for checking that the
> compile fail tests has triggered the static assert.
> 
> Ideally, the BCMTest module can make this simpler:
> 
> http://bcm.readthedocs.io/en/latest/src/BCMTest.html
> 
> Which you can write the equivalent tests like this:
> 
> Run test:
> bcm_test(NAME footest SOURCES footest.cpp)
> 
> Run fail test:
> bcm_test(NAME footest SOURCES footest.cpp WILL_FAIL)
> 
> Compile test:
> bcm_test(NAME footest SOURCES footest.cpp COMPILE_ONLY)
> 
> Compile fail test:
> bcm_test(NAME footest SOURCES footest.cpp COMPILE_ONLY WILL_FAIL)

Thanks !

> 
>>
>> Does CMake have an equivalent to the Boost Build alias rule ?
> 
> You can create interface target that includes the set of targets.
> 
> add_library(core INTERFACE)
> target_link_libraries(core INTERFACE im reader writer)

Thanks I will look at the use of INTERFACE.

> 
>> or the
>> Boost Build project rule ?
> 
> Hmm, I am not sure how this is relevant to cmake.

For the purposes of unit tests the project rule lets the developer set 
usage requirements for all tests in the jamfile, rather than having to 
repeat the usage requirements for each test. Since usage requirements in 
Boost Build can be pretty specific depending on the compiler being used 
the entire usage requirements for all tests can be pretty extensive. 
Having to repeat that extensive list of usage requirements for every 
test would be a PITA.

> 
>>
>> The great majority of the Boost libraries are header-only libraries
>> where Boost Build is used to run the unit tests and, optionally, Boost
>> Build is used to build the documentation using a quickbook, boostbook,
>> doxygen toolset to generate html and pdf files. While I realize that
>> building a Boost library, and making that built library available to
>> end-users via CMake, has been the focus of most of the discussion so far
>> regarding CMake and Boost, I am assuming the move to CMake also means
>> that running unit tests and building docs where applicable must also be
>> done through CMake. If I am wrong about this then I personally will be
>> only too happy to continue using Boost Build to do these things.
> 
> There has been cmake written in the past that has done the documentation, I
> don't recall where it was at. Either way, why do you think that generating
> documentation is not possible with cmake?

I never said that generating documentation from the 
quickbook/boostbook/doxygen tools was impossible with CMake. I would 
love to be shown how to do it, since it is pretty flexible with Boost 
Build jam files.