On Wed, Oct 5, 2016 at 11:07 AM, Klemens Morgenstern <klemens.morgenstern@gmx.net> wrote:
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 supports JSON
natively for that matter. https://sqlite.org/json1.html

I think you might be underestimating the power, speed, and quality of SQLite.
And the clarity of thoughts about the build state that the process of formally
modeling it in relational 3rd normal form brings to the table. My $0.02 :) --DD