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@lists.boost.org> 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