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