Subject: Re: [Boost-build] The future of B2?
From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2016-10-05 05:43:16
On Wed, Oct 5, 2016 at 11:07 AM, Klemens Morgenstern <
> Now for the build "minutia" format, I'd strongly advocate for SQLite.
> Because it's small, fast, smart, fantastic IMHO.
> It would force to model properly the build state in relational form, and
> allow any tool to extract information about
> the build with just a few queries. No JSON parsing; incrementally
> updatable; compact since binary.
> [...] 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. That state exists in the Python or C++
datastructures already, in some
form or another, but often not as declaratively as it should be, and the
fact its transient in the process and
always needs to be reconstructed and computed from scratch on every
invocation (ignoring a daemon
process caching it in memory), which for large builds is not cheap at all,
is a problem.
The process of modeling something to relational forces you to express the
build model in a very
declarative manner, independent of the idioms of any programming language,
and the fact that
SQLite representation is persistent and "complete" is invaluable IMHO.
And JSON can easily be generated from that SQLite state. SQLite now even
natively for that matter. https://sqlite.org/json1.html
I think you might be underestimating the power, speed, and quality of
And the clarity of thoughts about the build state that the process of
modeling it in relational 3rd normal form brings to the table. My $0.02 :)
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