Re: [Boost-build] The future of B2?

Subject: Re: [Boost-build] The future of B2?
From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2016-09-28 09:33:13

On Tue, Sep 27, 2016 at 8:48 PM, Edward Diener <eldiener_at_[hidden]>
wrote:

> [...] I think the main thing that is holding back better use of Boost
> Build is the fact that it is very difficult, if not impossible, for an
> end-user of Boost Build to understand how the final command line parameters
> are generated for a particular rule. In other words, given the plethora of
> ways in which options for a rule, such as 'compile' or 'link', are
> specified, whether via a toolset, a project, a rule, or the command line
> itself ( did I miss anything ? ),  I think it is important for the end-user
> to understand how he can change things to add, subtract, or replace a given
> command line option for commands generated from a rule. Clearly merely
> adding some Boost Build feature to the command line does not always work as
> one suspects it should. Since the process for generating command lines for
> rules in a jam file is pretty complicated end-users of Boost Build become
> completely lost in trying to understand how to change the way Boost Build
> creates commands, and this means that Boost Build is much less "usable"
> then it could be.
>

Completely agree with Edward on this one.
Abt it's not specific to Boost.Build by any means either.

I've worked on complex Ant builds in the past,
and Makefiles, IMake, etc... All build system suffer
from this to some extent. In many you can turn verbose
or debug mode, but that spews information about anything
and everything, while figuring out why you have this particular
command line for that file in that project is much more targeted.

One tech that resonated with me along these lines, from a long time
ago in the Java world, was Tapestry, which kept track of where all/most
state came from, including the various revisions of that state along the
time axis,
such that you could tell when something wrong happened, where the state at
the failure point was coming from. Only article I can find along this lines
now is
http://tapestryjava.blogspot.fr/2011/10/tapestry-feedback.html

My point is that in a build system, it's not only the final command line
forked,
or the syntax used, or the quality of the build engine that matters, but
also how
easy it is as Edward rightly puts it to figure out how to affect that
command line
and where the current command line comes from. Combining abstractions
configured in various places into a command line is great, but mapping that
command line back to its abstractions is almost never available.

it's a bit like the difference between a traditional (forward-only)
debugger,
and an omniscient debugger. The ability to go back in time, and to know
which
operations affected a particular value (in memory) is invaluable to
troubleshoot.
And that's what's missing from build tools IMHO.

My $0.02. --DD