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.
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost