Re: [Boost-build] Future of Boost.Build

Subject: Re: [Boost-build] Future of Boost.Build
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2017-07-27 03:12:13

Now that I'm back from my travels have some time to actually compose
something reasonable for this.. Which I was going to do tonight anyway :-)

On Wed, Jul 26, 2017 at 2:18 PM, Chambers, Matthew via Boost-build <
boost-build_at_[hidden]> wrote:

> Now that the shit has hit the fan, what will become of Boost.Build? I
> still prefer it to CMake even if Boost won't use it (whether I can convince
> my project to keep using it may be another matter). I have greatly
> appreciated Steven's, Vladimir's, and Rene's improvements over the years.
>
> Rene, can you expound on what you mention here?
>
> * I will continue to maintain Predef. But will be forking it into a
> non-Boost form moving forward (in similar vein to ASIO).
>
> That plan is.. I'm going to write a version of Predef that doesn't have
the "BOOST_" prefix on it. And generate the Boost version from it. That way
I can advertise Predef outside of Boost. As my industry, game development,
is still reticent to deal with anything Boost (and some in some notable
instances not even STL). And I'm seen the equivalent of Predef
reimplemented in every C++ project I've seen. So I'd like to see wider
usage of Predef. Hence I'm hoping this is the way to do it.

> * I will **not** continue to maintain B2 in the Boost form. I will be
> rewriting b2 into a new form to address the needs of building software that
> matches the industry I work in. I will be doing this immediately.
>
>
> What does it mean to rewrite b2 in "a new form" that "that matches the
> industry I work in"?
>

 Right.. Note, the following is what I want to happen not necessarily what
will happen. As this is also the first time the rest of the b2 devs see
this. So here goes..

First:

* The current b2 will get a cleanup and re-documentation pass.
* It will still operate the same way it does now.
* It will get improvements and adjustments.
* It will be easier to obtain (i.e. installers, website outside of Boost,
etc).

Second (although not necessarily sequentially):

* Rewrite b2 in a modular way to support uses other than the current b2
incarnation.

Ok, that was short and I should explain more. Over the years in my
industry, i.e. game development, I've worked on various systems. I've spent
much of that time writing and enhancing tools of all kinds. But almost for
most projects I've had to deal with either tweaking or writing new build
systems. The most recent of which was writing an entirely new build system
a couple months ago. One aspect that doing that is the realization that
everyone wants to make some custom build system and they are faced with
re-inventing all of it each time. I personally feel that this is one of the
largest drags on the quality of build system at the moment. What I want to
do is rewrite b2 such that it's based on parts that others can use to
create other tools for building. One of those tools would obviously be the
current b2 frontend itself. But there's also the current b2 Python port,
the faber tool from Stefan, b2 server/service helper, and tight IDE
integration modules to name a few. For this the general approach would be
to incrementally tear chunks out of the b2 engine (the C part) and replace
them with well thought out and documented equivalent library. There's
obviously way more detail to hammer out on this. But that'll be in other
discussions.

The big question from me in the above is.. What do you (that's a royal you
for anyone on this list) think of the approach?

> I will be particularly irked if the Boost SC ends up hiring contractors to
> speed the conversion to CMake, when the issues in Boost.Build
> (documentation and it being quite hard to learn how to do advanced things
> with it) could be solved by far less contracted effort.
>

Indeed.

And thanks for asking.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/skype,efnet,gmail