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 14:41:01

On 7/27/2017 8:43 AM, Florent Castelli via Boost wrote:
> On 26/07/2017 20:49, 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 ?
> 
> In my own Boost-CMake project, I have implemented regular "RUN" in a way 
> that looks similar to the original Boost Build using functions: 
> https://github.com/Orphis/boost-cmake/blob/master/libs/system.cmake

What is RUN supposed to be in your link above ?

> Other commands should be easy enough to implement as well, but I haven't 
> had the interest in doing that in my project yet (which predates the SC 
> decision).
> 
> It is possible to do "compile" by creating a regular static library 
> target with that file and then invoking "cmake --build . --target 
> <compile test name>". Compile failures can be done similarly and check 
> they fail.
> Link and Link-fail can be done the same way using actual binaries that 
> are built, but not run.

This is a poor solution.

> 
> The difference is making sure you have a clear separation of building 
> Boost itself and running the tests. I found out that failures are pretty 
> common with those tests and many of them will fail to run without errors 
> on all supported compiler and platform, so isolation is quite important.

Again I need to mention that the tests are run for header only libraries 
which are not "built" at all in most cases.

> 
> The problem is that some build tools will not support parallel 
> invocations (Ninja doesn't for example, see 
> https://groups.google.com/forum/#!topic/ninja-build/4VP7whvWSH8 ) and 
> thus running tests would be need to be linearized or moved to make, 
> which should support that scenario better.

That is the end-users problem. I am just interested in Boost solving its 
own problem of moving from the Boost Build testing rules to something 
with CMake which does the same thing.

> 
>>
>> Does CMake have an equivalent to the Boost Build alias rule ? or the 
>> Boost Build project rule ?
>>
>> 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.
> 
> CMake support header-only libraries using the INTERFACE keyword of 
> "add_library()". Those will propagate usage requirements like any other 
> library to their users. You can have you tests depend on those easily.
> 
> You can always have custom targets in each library to generate their 
> documentation in any way you like.
> Building the documentation for the whole Boost project can be done by 
> building all of those targets.
>