Re: [boost] Switch to CMake -- Analysis

On 21 July 2017 at 21:53, Artyom Beilis via Boost wrote:

On Fri, Jul 21, 2017 at 9:36 PM, Chris Glover via Boost wrote:

...

On Fri, 21 Jul 2017 at 13:25 Andrey Semashev via Boost < boost@lists.boost.org> 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... [6] https://github.com/mloskot/qt-creator-plugin-boostbuild Best regards, -- Mateusz Loskot, http://mateusz.loskot.net