Boost logo

Boost :

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.
>


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