<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 28, 2016 at 8:33 AM, Dominique Devienne <span dir="ltr"><<a href="mailto:ddevienne@gmail.com" target="_blank">ddevienne@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 27, 2016 at 8:48 PM, Edward Diener <span dir="ltr"><<a href="mailto:eldiener@tropicsoft.com" target="_blank">eldiener@tropicsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_5746585322482975783gmail-HOEnZb"><div class="m_5746585322482975783gmail-h5"><span style="color:rgb(34,34,34)">[...] 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.</span></div></div></blockquote><div><br></div><div>Completely agree with Edward on this one.</div><div>Abt it's not specific to Boost.Build by any means either.</div><div><br></div><div>I've worked on complex Ant builds in the past,</div><div>and Makefiles, IMake, etc... All build system suffer</div><div>from this to some extent. In many you can turn verbose</div><div>or debug mode, but that spews information about anything</div><div>and everything, while figuring out why you have this particular</div><div>command line for that file in that project is much more targeted.</div><div><br></div><div>One tech that resonated with me along these lines, from a long time</div><div>ago in the Java world, was Tapestry, which kept track of where all/most</div><div>state came from, including the various revisions of that state along the time axis,</div><div>such that you could tell when something wrong happened, where the state at</div><div>the failure point was coming from. Only article I can find along this lines now is</div><div><a href="http://tapestryjava.blogspot.fr/2011/10/tapestry-feedback.html" target="_blank">http://tapestryjava.blogspot.<wbr>fr/2011/10/tapestry-feedback.<wbr>html</a> <br></div><div><br></div><div>My point is that in a build system, it's not only the final command line forked,</div><div>or the syntax used, or the quality of the build engine that matters, but also how</div><div>easy it is as Edward rightly puts it to figure out how to affect that command line</div><div>and where the current command line comes from. Combining abstractions</div><div>configured in various places into a command line is great, but mapping that</div><div>command line back to its abstractions is almost never available.</div><div><br></div><div>it's a bit like the difference between a traditional (forward-only) debugger,</div><div>and an omniscient debugger. The ability to go back in time, and to know which</div><div>operations affected a particular value (in memory) is invaluable to troubleshoot.</div><div>And that's what's missing from build tools IMHO. </div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>My $0.02. --DD</div></div></div></div></blockquote><div><br></div><div>I'll take those two cents ;-)</div><div><br></div><div>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.</div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- Rene Rivera<br>-- Grafik - Don't Assume Anything<br>-- Robot Dreams - <a href="http://robot-dreams.net/" target="_blank">http://robot-dreams.net</a><br>-- rrivera/<a href="http://acm.org/" target="_blank">acm.org</a> (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail</div></div> </div></div>