Re: [boost] CMake and Boost Build tests

Subject: Re: [boost] CMake and Boost Build tests
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-07-27 05:12:44

On 7/26/17 7:28 PM, Edward Diener via Boost wrote:

> But the case I brought up is that there is no "build' of the library, 
> since it is header only, but the library needs to execute its tests 
> using CMake. That appears to me to be different from your case.

Well, there is the safe numerics library which has CMake tests and is 
header only.  It's much simpler than the serialization library.

https://github.com/robertramey/safe_numerics

You'll find a few CMakeLists.txt files in different places like 
include/example/test etc.  Not that much unlike bjam where one has jam 
files in test, example, etc.

> 
> So you are saying that even when their is no actual library to be built, 
> as is the case with a header only library, you still specify a 
> CMakeLists.txt file as if you were building a library ?

yep - just like for bjam you specify a jam file in the test directory, 
for CMake you specifiy a CMakeLists.txt file in the test directory.

>> This is a serious short coming of CMake.  Given this it's a mystery 
>> that CMake has been successful.  But then then look at all the 
>> competition it's ever worse!!!  To addressed this, I wrote a walk 
>> through in the boost library inclubator to help library developers get 
>> started with CMake.  It uses on the safe numerics library CMake as an 
>> example.  This example/narrative addresses only header-only files.
> 
> Would you please give a URL ?

https://github.com/robertramey/safe_numerics

I'm really disappointed you couldn't find this.  It recently was 
reviewed for inclusion in boost and accepted!

> Do you know if CMake has a way of setting usage requirements for all 
> builds in a directory ? That is the effect of the project rule in Boost 
> Build when running tests. It is very useful and means that you do not 
> have to repeat a bunch of usage requirements for each and every test.

Right.  Every build system has to address this problem.

In bjam I can make a "rule" which passes "usage requirements".

In CMake I make a "function" which passes arguments.

Similar but different.  For some reason every build system designer 
seems to fancy himself a language designer and what we get is some 
oddball/irregular "language" for describing the "build".  When it barely 
works the release and then start patching it up to so it can be made to 
work.  The result is what we have to today.  An assortment of build 
languages none of which are very good.  This is addressed by inventing a 
NEW build language which isn't really any better than the one it's meant 
to replace.  This happens again and again - this is how we came to be 
where we are today.

> I will look at your serialization CMake code and I assume the other 
> working example is for your Safe Numerics library, so I will look at 
> that also. Thanks !

There are other examples already in boost - made by people who know more 
about CMake than I do.  (I hate wasting time on this kind of stuff). 
Unfortunately, many of these examples seem to be more elaborate than 
necessary and end up totally obscuring that which starts out simple. 
Its a chronic programmer disease to start with something understandable 
which works and then try to make it perfect there by mucking it up. 
Hollywood plastic surgeries have the exact same problem.

>> I've got a lot to say about this and I will be giving a presentation 
>> on the subject at CPPCon 2017 for anyone who might be interested.  
>> That is the both of you.
> 
> I did not realize I was a split personality <g>.

Hmmmm - It didn't occur to me that you might be going to CPPCon.  So I 
guess I'll plan for three then.

Robert