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:45:25

On 7/27/2017 8:12 AM, Florent Castelli via Boost wrote:
> On 27/07/2017 10:24, Edward Diener via Boost wrote:
>> On 7/27/2017 1:12 AM, Robert Ramey via Boost wrote:
>>> 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.
>>
>> Great, thanks !
>>
>>>
>>>
>>>>> 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!
>>
>> You said you wrote a walk through in the boost library incubator and I 
>> asked for the URL of the walk through. You gave me a link to your safe 
>> numerics library on github. I have found 
>> http://blincubator.com/tools_cmak/. I will read this.
>>
>>>
>>>> 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".
>>
>> You do not have to make a rule since the builtin "project" rule 
>> already does this for you.
>>
>>>
>>> In CMake I make a "function" which passes arguments.
>>
>> So CMake has no way built-in command to say "here are the usage 
>> requirements for every target in this directory" other than to have to 
>> write a "function" each time ? That seems a bit poor.
> 
> It does has some support for things like that, but it scales poorly. 
> What you can do instead is have a target with all the requirements you 
> want and link against it and they will bubble up.
> Or you just use a function, which is not a bad thing, they can remove a 
> lot of boilerplate and make the intent clearer.
> Would you write ASM all the time? No, you write high level C++. A build 
> system is no different.

What would be the CMake syntax for such a target ? In Boost Build the 
'project' rule lets you set requirements. How would I do that with your 
target. Some CMake code please ?

> 
>>
>>
>>>
>>> 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.
>>
>> No I don't go to CPPCon but if you can get programmers to create 
>> better documentation by your talk there I am all for it.
>>
>>>
>>> Robert