Re: [boost] CMake - one more time

Subject: Re: [boost] CMake - one more time
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2016-04-20 18:26:02

On Wed, Apr 20, 2016 at 4:39 PM, Raffi Enficiaud <
raffi.enficiaud_at_[hidden]> wrote:

> Le 20/04/16 17:49, Robert Ramey a écrit :
>
>> Inspired by the recent discussion regarding CMake, I've spend some more
>> time looking at this.  As a result, I've done the following.
>>
>
> Hi,
> Thanks for summarizing this very very (very) long thread.
>
>
>> a) I experimented with using CMake in the more customary manner in my
>> canonical project Safe Numerics - (see Boost Library Incubator). The
>> current version does distribute CMakeLists.txt around the subdirectories
>> of the library root.  My original objections to doing this were assuaged
>> when I realized that boost build does the same thing.  That is I
>> typically have Jamfiles in side of test, example and sometimes other
>> directories.
>>
>> b) One of the features that I much like about Boost Build is the
>> possibility of arbitrary nesting of Jamfiles.  This permits one to
>> build/test a portion of one's library (e.g. test, example) as well as
>> the whole library.  For a large library this is indispensable. In spite
>> of what many people think, this is not easily supported with CMake.
>> However, I have found that with some extra effort, it is possible to
>> support this to the extent we need it.  So in this project ONE CAN BUILD
>> (actually create an IDE project or makefile that builds) ANY OF THE
>> "SUBPROJECTS" (TEST, EXAMPLE) AS WELL AS THE LIBRARY "SUPERPROJECT"
>>
>
> If you think about nesting as being able to run something like "make doc"
> from any library, then yes, cmake is definitely lacking that. OTOH, I have
> the feeling that:
> 1- everything in the current boost is coupled to the build system. I read
> ppl wanting to be modular, but it is given the fact that there is an
> adequate build system
>

I don't know what you mean by everything. Technically, you don't need BB
when *using* Boost. Most libraries work header only which means just adding
to your include path. And others should be build-able by adding their
source to your project. And some libraries already support modular use.

2- b2 is a bit cheating: it knows the full "namespace" (it flattens it) and
> can then eg. sort out the targets dependencies and build order. So even if
> you think that by typing "make doc" in your library, you are hitting only
> the build system (boostbook/doxygen toolchain, etc) plus your library, this
> is wrong: every target in b2 has the knowledge of the full DAG of
> dependencies, which makes it highly coupled to any other library, at least
> to the superproject.
>

Ah, I don't think so. BB ingests as many targets as it's told to. It so
happens that the integrated Boost distribution reads all the sublibraries.
And hence reads all the build-able targets. But this is *only* an aspect of
the integrated Boost.

> In CMake this nesting of CMakeLists is more compartmented: one CMakeList
> is supposed to be more or less independent from its siblings (but not from
> the parent). This is also what would make the transition of the super
> project to CMake very difficult: for instance dependencies have to be
> explicitly stated in a main orchestrating CMakeLists.txt (in b2 this is I
> believe implicitly done, certainly is several parsing passes).
>

Which is actually the same as b2.. With the exception that we've put extra
logic to make managing all those dependencies as easy as possible for
library authors in the integrated Boost.

>
> 3- b2 imposes a structure of directories as well: for instance, if I do
> """
> using quickbook ;
> using doxygen ;
> using boostbook ;
> """
> those features should be in files relative to some paths of the b2
> location wrt. the superproject (please correct me if I am wrong).

You are wrong :-) Those modules are searched for in a variety of
predetermined and user configurable set of directories. One of those
directories happens to be automatically configured to include the sources
of b2 as included in the integrated Boost. Again, to make it easier for
library authors and end users.

> Also, when I "make" a library, it goes magically to the bin.v2 folder of
> the root of the superproject.

Yes, this is a directory specified by the integrated Boost build files (<
https://github.com/boostorg/boost/blob/master/Jamroot#L173>).

> I have the feeling that some behaviour of b2 in terms of relative paths
> are hard-coded somewhere.
>

Many behaviors in b2, and in cmake, and in just about all build systems,
are "hard-coded". For b2 they should already be documented. But you
probably mean something other than what I'm understanding by "hard-coded"
:-)

> That is to say that: "cd doc; b2" is not at all independent from the
> superproject folder structure, and the apparent modularity is not a real
> one. But again, I agree that is just works for the purpose of boost, it is
> just tightly coupled to hidden things.
>

It's actual modularity. And is independent of the superproject. If you want
an example check the Predef library. I build the documentation outside of a
Boost superproject. But obviously I need some form of Boost distribution to
build the documentation tools. But it doesn't need to be a full
distribution (and yes I've done it with a minimal distro). And it's also
possible to build the Predef docs without any Boost distribution (which
I've also done), as long as you set up b2 to inform it of pre-built doc
tools.

> I do not like the current state of b2 for many reasons (even though I
> think it could be really a good build system), but CMake is not covering
> many features that are currently required by the boost superproject. Until
> the point where we can consistently build the lib (including the possibly
> many flavor of the same library - STATIC/SHARED at the same time, etc), run
> the tests, and generate the documentation (including the possibility to
> have the boostdoc/quickbook/doxygen toolchain), I do not see any *good*
> reason to move to cmake.

That's essentially the conclusion that the community ended up with years
ago on the first attempt to implement cmake support. And I would like to
know what the reasons for not liking b2 are. But on the b2 list ;-)

>
>
>
>> Some Conclusions - I'm trying to not make this a rant
>>
>> a) The ideal, platform independent build system does not yet exist.  I
>> guessing it never will.  I'm sure it won't happen in my life time - but
>> then I'm 68 - maybe you'll get lucky.
>>
>> b) Both systems are much more fragile, complicated and opaque than their
>> promoters try to make you believe.  It's not that they're lying, they
>> truely believe in their own stuff.  There is much re-invention of the
>> wheel - The each created their own (half-assed) little language for
>> goodness sake!!!
>>
>> c) Neither has really resolved the issue of nested projects in a clear
>> way.  Boost Build probably does or can do this.  CMake has a system of
>> "packages" and a whole 'nuther layer about "finding" them.  Assuming it
>> can be made to work - given the amount of time I've invested in CMake, I
>> should know how to do this by now.
>>
>
> At least, one is more or less working right now, and the other has not
> proven to be working in all variety of cases.
>
>
>> d) I think it's time for Boost to be a little more open about
>> tolerating/encouraging alternative build systems.  I think our
>> documentation approach is a model.  Yeah it's a hodgepodge.  But the
>> various ways of doing pretty much work and generally don't stop working
>> and we don't have to constantly spend effort bringing things up to the
>> latest greatest system (which we couldn't agree upon anyway).  We have
>> libraries which have been going strong 15 years - and people can still
>> read the docs.
>>
>
I should point out that we do "tolerate" other build systems. After all
we've had libraries support make and VisualStudio in the present and past.
We just require that libraries support b2. As supporting differing build
systems at the same time would be insanity, and likely impossible, for
infrastructure support.

I have to say this does not scale at all, especially wrt. the resources
> (your point e/ below). I do not know if the documentation is a good example
> also: we have many different systems, I like quickbook, I believe it is
> properly serving the purpose of a "documentation", where Doxygen fails.
> What is the cost of maintaining many tools compatibility? I would promote
> the opposite in fact: some methods proved to be good for boost, if someone
> wants to integrate with a currently unsupported tool, it should not so much
> impact the ppl that are eg. maintaining the travis.yml (or they should do
> the work). Also the tools are at the core of boost, we should not neglect
> them and rather promote them as we do for boost libraries, and we should
> not integrate technologies that are weak, "just because" it makes boost
> more appealing for a few developers.

+1

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail