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

Subject: Re: [Boost-build] The future of B2?
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2016-10-03 22:47:31

On Wed, Sep 28, 2016 at 8:33 AM, Dominique Devienne <ddevienne_at_[hidden]>
wrote:

> 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
>

I'll take those two cents ;-)

The one idea I have for this, which is partly like the Tapestry work you
mention, is to track any property set changes to the context that made the
change. I.e. keeping a history of partial stack, project, and target made
the change. This would work as b2 is driven almost entire through the
property sets. With that information one could indicate precisely why an
action has certain options. Regardless of where we need to report that
information.

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