Re: [boost] Switch to CMake -- Analysis

Subject: Re: [boost] Switch to CMake -- Analysis
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2017-07-21 21:32:04

On 21 July 2017 at 21:53, Artyom Beilis via Boost <boost_at_[hidden]> wrote:
> 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.
> ------------------------------------------------------------------------
>
> [...]
> 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'd like to second Artyom's comments here.
Boost.GIL may serve as another example - with I/O API depending on
number of external libraries to support raster formats.

Back in 2010, during and long after the GIL review, I remember Christian Henning
(author and maintainer of GIL) and myself, we were having hard times over long
months trying to complete the Boost.Build setup for the library.
I don't remember if eventually Christian released GIL with user
friendly support for
third-party libraries.
I'd been trying to convince myself [1] to like Boost.Build Extensions
[2] for some time.

For several years after, I'd be lurking around the numerous Boost.GIL bugs on
the Trac trying convince myself to pick and work on some, but the Boost.Build
adventure was putting me off, effectively.
Eventually, I gave up looking at GIL completely.

I was involved in Boost.Geometry for quite some time, especially during period
following the review. Since Boost.Geometry does not require any dependencies
Boost.Build configuration was pretty straightforward.
Not for examples [4] and (some) tests though. For those, it turned to easier to
maintain copy of third-party libraries in-source [5]. Boost.GIL
adventure repeated.

In my experience, Boost.Build works great to build...self-contained Boost.

For an ad-hoc/supporting contributor to Boost, Boost.Build often
proved to be hurdle
hard to get over. I think that may be the case for many developers who
have free slot
of time on a Sunday afternoon and want to pick and shoot a bug in a library.
Lucky one, if the library is external dependencies-free.

To defend my position as willing and not as biased against Boost.Build
as it may seem, a while ago I developed Boost.Build plug-in [6] for Qt Creator.

OTOH, I have love-n-hate view on CMake, but I can at least
a) transit knowledge between projects
b) configure build via command line
c) browse huge number of CMake-ified projects on GitHub to learn about
good CMake configurations (CMake docs is a syntax/commands _reference_,
but it is Shit in terms of presenting idiomatic and complex
configurations, best practices,
do's and don'ts, and often outdated Wiki does not help either)

[1] http://mateusz.loskot.net/post/2010/10/17/notes-on-boost-build-for-boost-gil/
[2] https://svn.boost.org/svn/boost/sandbox/tools/build_extensions/
[3] https://github.com/mloskot/boost-gil-workshop/tree/gil-io2-gdal
[4] https://github.com/boostorg/geometry/tree/develop/example/with_external_libs
[5] https://github.com/boostorg/geometry/tree/develop/example/with_external_libs/contrib
[6] https://github.com/mloskot/qt-creator-plugin-boostbuild

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net