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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk