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

Subject: Re: [Boost-build] The future of B2?
From: PJB (darthpjb_at_[hidden])
Date: 2016-10-05 06:05:56

On 5 October 2016 at 10:43, Dominique Devienne <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.