<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 5 October 2016 at 10:43, 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"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">[...] I don't think we need
(or should) store the state of the build in any form, i.e. writing a
json or SQLite somewhere which tells you what's built and what's
not.</div></blockquote><div><br></div><div>I didn't mean that state (which is necessary for incremental builds IMHO, but that's a different debate),</div><div>but the "essence" of the build, i.e. how to build all targets, why (dependencies), basically all the same info</div><div>present in the set of human readable declarative files, but parsed/digested/expanded to be available to</div><div>any other tool to consume as-is.</div></blockquote></div><br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(19,79,92)">I cannot express enough the importance of both the concept of storing build-states, as well as the transitional data during a build.<br><br>There is no scenario as offensive to the senses as walking into work on Tuesday to be told "The version from Friday doesn't work, fix it" - Any programming house with a QC department has to deal with a simple and essential issue. People that are not programmers have to test your software - often some time after it was built.<br><br>The ease of automating the build process is only half the life-cycle of a build system, providing an interface through which build-states and errors can easily be retrieved is essential - often the tooling for such a scenario is done in house, presented as a intranet page to the QC staff.<br>In these situations Developers need feedback as to the build state, if possible <i style="font-weight:bold">before</i> QC are aware a build has even been made - and in the event of failure, knowing what failed means knowing who needs to solve the issue.<br><br>In my companies scenario, we have fourteen software products - the nightly build system provides these as windows installers as well as Apple-DMG files.<br>Often errors are caused by simple network problems (system-admin issues), but some of our software is compiled with six different languages, through four different build processes - each has a different developer responsible.<br><br>I'm certainly not proposing a build system be some cure-all to these issue, however being capable of programmaticaly retrieving the state of a build, as well as the cause behind a failed build is a feature that should be seriously considered.<br><br></div><br></div></div>