Re: [boost] [SPAM] Re: Informal CMake meeting at CPPCon

Subject: Re: [boost] [SPAM] Re: Informal CMake meeting at CPPCon
From: Robert Dailey (rcdailey.lists_at_[hidden])
Date: 2018-01-12 15:38:48

On Tue, Oct 3, 2017 at 11:27 AM, Robert Ramey via Boost
<boost_at_[hidden]> wrote:
> On 10/3/17 8:18 AM, Louis Dionne via Boost wrote:
>>
>> Boost - Dev mailing list wrote
>>>
>>> On Mon, Oct 2, 2017 at 9:16 AM, Stefan Seefeld via Boost
>>> &lt;
>>
>>
>>> boost_at_.boost
>>
>>
>>> &gt; wrote:
>>>>
>>>> Have you discussed the possibility for the two (Boost.Build and CMake)
>>>> to coexist...
>>>
>>>
>>> David Sankel made it pretty clear that in the "final solution", CMake
>>> will be mandatory and Boost.Build will be optional. Unless I
>>> misunderstood (David, feel free to correct me).
>>
>>
>> I don't remember anyone making that statement.
>
>
> Hmmm - I do remember getting that impression though it may not have been
> explicitly stated.  My reaction was to point out that we didn't have to
> address this issue until we actually had a real CMake alternative for Boost.
> I think this got us over the hump to where could find some common ground on
> something that would move us forward.  Of course I don't remember every word
> and detail now.  But I believe that my original summary captures the
> essential sense of the mercifully short and in my view productive meeting.

I want to revive this old thread, because I think it's extremely
important. I've been using CMake since around 2007 and I'm extremely
familiar with it. If the Boost developers plan to support CMake or
have an ongoing repository with CMake scripts they're working on,
please share it with me as I'd love to pitch in.

Having said that, I want to be frank. I apologize in advance if this
offends anyone. My goal is to not offend anyone's efforts, I just want
to be brutally honest for a moment.

Boost Build is an abomination of a build system. It's a complex and
niche system designed (from my perspective; not sure what the real
intent was) just to build boost. It has an extremely steep learning
curve and even the most basic build instructions are incredibly
complex. Forget cross compiling. Why should I have to define a
user-config.jam that specifies over 20 compiler arguments? If you've
never tried to build boost for Android, then forget doing it with
bjam. First, try doing a google search to see how others have solved
the problem. You will literally never see the same solution twice.
Furthermore, instructions you find are very dependent on the specific
version of NDK and Boost combination used for those instructions. You
could spend days going through dozens of solutions but never find one
that works.

The point of all my venting is that bjam is not sustainable as a
public facing build system for Boost. I get that the boost devs are
probably already very familiar with it and that makes them comfortable
with it. But the users and builders of the Boost library struggle with
it constantly. It's not something I have used in my 15+ year career as
a software engineer outside of building boost, which I do not do very
often. So there's no incentive for me to learn it and become familiar
with it beyond the "means to an end" task of getting the libraries I
have dependencies on.

I've been using a set of comprehensive CMake scripts to build boost
here: https://github.com/Orphis/boost-cmake

It makes it very easy to build boost consistently across multiple
platforms, including cross compiling to Android NDK. Furthermore, the
NDK already provides a CMake toolchain file to make the task of
building libraries for Android a trivial matter. This project is far
from perfect, as it's difficult to add support for building new
versions of boost. But I think it's a good start if the boost
developers do not have something they're working on already. I've been
working with the author to add proper install target support. I've
used it and it works great. So it's come a long way and I recommend
everyone take a look at it.

Lastly I want to just say that supporting multiple build systems
simply because a portion of the community is adverse to using CMake is
going to be extremely counterproductive. What you'll end up with is
the bjam developers not updating CMake, and the CMake developers not
updating the bjam build scripts. Happens every where I have worked
that has more than one build system in place. I really do not
recommend this approach. While more controversial, I recommend that
those that currently prefer bjam just make the switch to CMake as long
as it fulfills all the requirements. Having people's personal
preferences get in the way will just create unnecessary complexity.
Just thinking of this objectively.

Again I apologize for the frustration that's obviously leaking through
my email here. I love boost but for years I've dealt with the
frustration of having to build it. It should be a simple matter, but
like a some things in boost, the current build system is too
overengineered.