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

Subject: Re: [Boost-build] The future of B2?
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-10-05 06:40:19

Am 05.10.2016 um 12:05 schrieb PJB:
> On 5 October 2016 at 10:43, Dominique Devienne <ddevienne_at_[hidden] 
> <mailto:ddevienne_at_[hidden]>> wrote:
>
>         [...] 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.
>
>
>     I didn't mean that state (which is necessary for incremental
>     builds IMHO, but that's a different debate),
>     but the "essence" of the build, i.e. how to build all targets, why
>     (dependencies), basically all the same info
>     present in the set of human readable declarative files, but
>     parsed/digested/expanded to be available to
>     any other tool to consume as-is.
>
>
> ​I cannot express enough the importance of both the concept of storing 
> build-states, as well as the transitional data during a build.
>
> 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.
>
> 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.
> In these situations Developers need feedback as to the build state, if 
> possible /before/ 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.
>
> In my companies scenario, we have fourteen software products - the 
> nightly build system provides these as windows installers as well as 
> Apple-DMG files.
> 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.
>
> 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.
>
Makes a lot of sense, and if you thus are able to store the current 
git-hash (or svn-revision) and all the build settings for your report, 
you'd be fully informed. But the sink you put into shouldn't be part of 
the build-system core but a plugin, because most companies will have a 
custom solution for that.

I don't know if it's currently available in boost.build, but a on-fail 
rule could take care of that (not sure about the syntax though):

lib foo : bar.cpp ;
on-fail foo : do-something ;

And then you could do the same for project-root.

on-fail project-root : report-it-somewhere ;

There you could then put the information whereever you like, SQLLite, 
Json, Insulting Mails to coworkers.

Another Idea I had: maybe this could be inverted also. So I not only 
provide the information, but I share my build-results on a platform, 
which allows me to get them from there, provided they have the same 
properties. That would allow a sort of package-manager which would be 
fully described. I.e.

package-server pkg = some.where.on.my.network ;

pkg lib foo : bar.cpp : <link>static ; # checks if this binary, with all 
implicit dependencies etc. is availabe; if not it builds it and pushs it up.