Re: [boost] Switch to CMake -- Analysis

Subject: Re: [boost] Switch to CMake -- Analysis
From: Artyom Beilis (artyom.beilis_at_[hidden])
Date: 2017-07-21 19:53:56

On Fri, Jul 21, 2017 at 9:36 PM, Chris Glover via Boost
<boost_at_[hidden]> wrote:
> On Fri, 21 Jul 2017 at 13:25 Andrey Semashev via Boost <
> boost_at_[hidden]> wrote:
>
> You'll also need whatever version of the *actual* build system CMake is
> generating for. So, we go from having 0 dependencies to at least 2: CMake
> itself, and the target build system.
>
> -- chris
>

I think this exactly summarizes both advantage and Achilles heel of Boost.Build
and the entire vision of Boost Community.
------------------------------------------------------------------------

Boost.Build is ok for 100% self contained library that needs nothing but
itself and boost.

This why declarative approach of BB actually works not bad and you can run
from single line build of multiple variants.

However the REAL WORLD isn't that "perfect". In real world scenarios boost
libraries require complex configuration and depend on 3rd part libraries.

This requires complex configuration - search for libraries, headers running
some checks. This makes BB declarative/tags approach programming
nightmare.

As the author of Boost.Locale library that has complex dependencies and
build options I can say it is impossible to maintain complex projects with BB.

Why:

1. Support of basic features given by any normal REAL WORLD build
system barely exists (library search configuration options etc)
2. Documentation isn't good and it was this for years.
3. Knowledge exits only for few people.

Do you want a proof? Please find me a tutorial how to search a 3rd
part library or complete
reference documentation for that.

I mean:

(a) find if library exists (with optional search path)
(b) find if headers exists (with optional search path)
(c) given this turn on and off some feature of fail library build
(d) propagate results to tests.

And this is one of the most basic and trivial feature that exists in every
real world build system.

And now take a look on this code:

https://github.com/artyom-beilis/cppcms/blob/master/booster/CMakeLists.txt#L124

Lines 124-145 this is how I search ICU for Boost.Locale

And this is how it is done in BB:

https://github.com/boostorg/locale/blob/develop/build/Jamfile.v2#L63
Lines 63-190

I look at the code and I can barely understand what is written. Options
that are in use aren't documented. And only very few people
on this list can describe me what is going on.

So please all of you complaining how Boost.Build is great in comparisons
to cmake and what cmake can't do. I want you to tell what BB can't do?
It can't support complex projects that aren't self contained properly.

I want also relate to another issue that was pointed there?

That CMake can't run

   ./b2 toolset=msvc-12,msvc-14,mingw

Boost.Build can't either once a 3rd part library required as search paths
for each need to be different. What about running?

./b2 -sICU_PATH=/opt/icu56 ..
./b2 -sICU_PATH=/opt/icu59 ..

And this is one of the principle issues of BB - its declarative way
of providing configuration.

---------

So I'm really thrilled by moving to CMake, not because it is perfect
build system - it isn't. But at least it (a) feature rich (b) well documented
(c) it works for many cases BB would required custom build macros

So instead of trying to live in pure world without dependencies please
consider thous who can't afford it.

Artyom Beilis