On Wed, Sep 28, 2016 at 8:33 AM, Dominique Devienne <ddevienne@gmail.com> wrote:
On Tue, Sep 27, 2016 at 8:48 PM, Edward Diener <eldiener@tropicsoft.com> 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

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