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

Subject: Re: [boost] [SPAM] Re: Informal CMake meeting at CPPCon
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2018-01-12 18:05:04

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Robert Dailey via Boost
> Sent: 12 January 2018 15:39
> To: Boost Developers
> Cc: Robert Dailey; Robert Ramey
> Subject: Re: [boost] [SPAM] Re: Informal CMake meeting at CPPCon
> 
> 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.

I hear your frustration (though I find that bjam works fine for me, and does some things that CMake can't).  But, by itself,
knocking bjam won't help).

There is a clear declared wish and willingness to make CMake work for building Boost.

Someone needs to make CMake 'just work' for people (including explaining how - it's all greek to me ;-) ).

(And it isn't going to be the people who have worked over many years supporting bjam - it is all they can do to keep bjam running).

It's no good trying to stop support for bjam unless CMake is really working well; I don't get the impression that it really is
working yet :-(

It is lack of CMake enthusiasts input is the missing thing here.

So yes, please, help make it happen.

HTH

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]