Re: [boost] Status of the CMake-ification

Subject: Re: [boost] Status of the CMake-ification
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2015-11-18 04:20:30

Le 17/11/15 17:06, Robert Ramey a écrit :
> [snip]
>
> a) Bjam has a steep learning curve.  CMake seems easier and it is - but
> it's still too complicated.

Also the community support in cmake is much stronger.

>
> b) Bjam permits one to have one build file refer to another.  CMake
> might permit this, but it's sufficiently unobvious that I couldn't
> figure it out.  This is useful for us.  For example if I want to build
> (and run) tests for the serialization library, it will automatically
> build the libraries it requires and nothing more - just by invoking the
> build script from within the test directory.  CMake might be able to do
> this - but it's very non-obvious how one would do this.

CMake works with targets. In bjam we can create a target (conjunction of 
source files and compilation options) on the dependent side (eg 
"/boost/thread//boost_thread/<link>static"), in cmake all targets should 
be declared prior to any reference (so "target_link_libraries(boost_test 
boost_thread_static)" will not work if boost_thread_static has not been 
declared).

>
> c) CMake couples all your directories together by sprinkling
> CMakeList.txt files throughout one's directory structure.  This is very
> intrusive and inconvenient as far as I'm concerned.  Bjam is better in
> this regard.

I do not see any difference between bjam and cmake in that regard. We 
have a Jamfile, we should have a corresponding CMakeList.txt.

> d) CMake "language" is simpler than BJam "language".  There both very
> inconvenient to use and understand.  But the "language"s, clunky though
> they are are good enough for the task. The real problem is that building
> applications these days is very, very, very complicated.  It's evolved
> over many years as applications have gotten more and more elaborate.
> Basically, it's a hard problem and the difficulty of making tools to
> help reflect that.

I agree that both are rather difficult (and have rather "nice" gotchas 
as). It however appeared to me that cmake is simpler to debug (better 
error messages).

>
> e) CMake builds the "build script" which Bjam builds the app.  This
> means that CMake can build my IDE for the project and BJam can't.  I use
> Apple XCode for an IDE.  Previously I used MSVC IDE to maintain the
> serialization library.  In both cases, maintaining these IDE by hand was
> difficult and time consuming (MSVC) and pretty much impossible (XCode).
> This one feature has made CMake indispensible to me.

I think this is a killer feature, and this is the reason why some ppl 
(including me) are maintaining a separate CMakeLists.txt today. I also 
did it in such a way that I can compile the documentation, run the 
tests, etc. directly from my IDE,

> f) CMake can't run a compile only test - or even more difficult - a
> compile test which has to fail - without some CMake gymnastics.  At 67 I
> don't go in for gymnastics so much any more.  Bjam handles this easily.

I can also say the same (although I am not yet 67). I do not want to 
learn a new language, especially when the languages I know are 
expressive enough for the tasks I am doing.

BTW, what you mention should be easily achieved with try_compile/try_run
- https://cmake.org/cmake/help/v3.0/command/try_compile.html
- https://cmake.org/cmake/help/v3.0/command/try_run.html

> I'm sure I could mention other stuff if I thought about it more.  But my
> conclusion is - if you're doing a project which is not boost - use
> CMake.  If you're doing a boost project - do both.

I should add the following:
First, despite its age, cmake is "still" very active in its development, 
and very well maintained. Its community is reactive, it has great 
support on the development and user site through its mailing lists. It 
also supports a very large number of architectures and modules.

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.
   - can graph the dependencies without any additional tools. This kind 
of introspection is to me very important for scaling up.
   - 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.
   - 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.

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.

To be honest, I do think that there are ways in cmake to address its 
current limitations. The super project may provide functions to eg. 
generate documentation from quickbook/doxygen as it does now, and the 
libraries will just consume those functions. The superproject might just 
expect build+test+doc as umbrella targets (or naming them in a special 
manner such as "<library>_<target>": "atomic_build", "test_doc"...), and 
the libraries should implement those targets in such a way that it 
builds everything needed ("test_doc" should call doxygen and quickbook, 
"test_test" should build and run all tests in boost.test, etc).

On the boost.test side, I am all for it for supporting this and for 
providing any template that might help and serve as starting point.

Raffi