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

Subject: Re: [Boost-build] Future of Boost.Build
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-07-27 12:17:58

On 26.07.2017 23:12, Rene Rivera via Boost-build wrote:

[...]

> 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 agree. There are quite a few idiosyncrasies that have crept into b2 to
support Boost-specific policies that I think a general-purpose build
tool shouldn't have (or that should be captured in a higher layer to
adapt the tool to a specific work-flow), but there is a substantial set
of generic features that each and every build system needs. Agreeing on
that core set of features and putting that into a form that's reusable
by others to define their own workflows would be very valuable.

I have tried to do that in Faber (where bjam survived as the scheduler,
but everything on top of it is rewritten in Python from scratch), and I
would definitely like to compare and share with others.

        Stefan
 

-- 
      ...ich hab' noch einen Koffer in Berlin...