Subject: Re: [boost] CMake and Boost Build tests
From: Florent Castelli (florent.castelli_at_[hidden])
Date: 2017-07-27 12:12:43
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
>> Well, there is the safe numerics library which has CMake tests and is
>> header only. It's much simpler than the serialization library.
>> 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
> 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
>>> Would you please give a URL ?
>> 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.
>> 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.
> Unsubscribe & other changes: