On 11/18/15 1:20 AM, Raffi Enficiaud wrote:
Cmake can do things bjam can't, from the top of my head: - can be used together with cdash for the regression tests/dashboard.
We will then not need to maintain the regression test suite within boost anymore. CDash is far from perfect, but it is effective.
This was very interesting to me and I implemented it for the safe numerics library. I also described in detail how to do it in the CMake section of the boost library inclubator advice. It does work - but it's really overly kludgy. The CDash/Continuous integration aspect isn't really polished enough. My short term goal was to provide a method of "on demand" testing and posting of results to a common dashboard for libraries not yet in boost. I was happy with the results - more or less - it was kludgy and the website hosting the results is hard to read and manage. It just needs a lot more work
- can graph the dependencies without any additional tools. This kind of introspection is to me very important for scaling up.
As I've said before - I'm skeptical of automatic dependency analysis tools.
- it is meant to be modular: if someone needs to link with opencl, this capability is confined in a specific module of cmake, with specific maintainers. The burden of having a cross platform support for opencl is not carried by boost. Same goes for libtiff, doxygen, python, etc. BJam just assumes that the toolset is available from the command line.
Maybe - but every time there there's a change in cmake version it requires refiddline with the CMakeList.txt files. It's just not as easy as it's made to sound
- it has installation and packaging semantics. I can for instance envision having boost binaries in their own PPA on Launchpad and distributing those quickly. I can also think about having a simple "make install" target.
I have to confess I've never understood the concept of "packaging" as it relates to a source code distribution.
What cmake cannot do right now: - easily specify a dependent build variant. With bjam, I can write /boost/thread//boost_thread/<link>static , with cmake, we need to define a specific naming convention for that, and this will not achieve the flexibility of bjam anyway. - easily specify new requirements. While those options are appearing in cmake >= 3 and support main stream compilers, they do not have the same power/flexibility as for bjam. It is also not clear to me how to extend the already supported compiler features. - cmake does not produce symbolic or hard links (on the fly) as b2 header does. But honestly, "b2 header" is an installation step prior to the build: it can be done in cmake as well, and I believe it would be better to remove that step anyway.
That would be a whole 'nuther discussion.
To be honest, I do think that there are ways in cmake to address its current limitations ....
I'm not unsympathetic to the whole idea. But I'm skeptical of ambitious plans to replace bjam "all at once". I would suggest that CMake enthusiasts encourage, support, and mentor authors who want to add CMake support to their libraries. If you can't get enough on board with this approach - you won't be able to make anything more ambitious work. And the best part of this idea is that we don't have to reach a boost wide consensus. I library writer has the right to do this on his own. All you have to do is get started. BTW, given your obvious experience with CMake, I'd welcome your thoughts on my thoughts written about CMake in the Boost Library Incubator. Robert Ramey