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

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