Re: [boost] Status of the CMake-ification

Subject: Re: [boost] Status of the CMake-ification
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-11-18 12:38:29

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