(7) Target output

That could probably be the easiest concept: the build-system should be able to output all targets with their config to the console, for example as json. This would allow an IDE to see all targets and provide the corresponding settings.

I would go further than that. A build system IMHO should have two stages:

1) A high level first stage, driven from a high level, declarative, human friendly syntax,
and input files, the whole lot processed by a smart engine to derive all the minutia of the build itself.
2) A lower level second stage, driven solely by a representation of the "minutia" in some format,
which deals with all the forking, parallelizing, progress reporting, etc...

Ok that makes sense, you could basically distingiush between top level targets and the complete build path. E.g.

lib foo : bar.cpp ;

Toplevel: Tells me foois generated from bar.cpp and tells me the properties of foo. The low-level gives every intermediate (i.e. bar.o) and all properties + all commands. Makes sense.
That would basically mean that I maybe also could intercept the actual calls and move them somewhere else (e.g. using incredibuild).


Boost.Build seems to be a strong candidate for the first stage (can't say myself, as most have surmised already),
but how well does it fare as a second stage?

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 wouldn't be very enthusiastic about that. 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 guess the better way would be to allow interaction with the status of the build system in the plugins. That is: you could write a plugin which puts all the current information into SQLite, I could built one writing it to Json etc.. That way you could build a plugin for each IDE and put it into a format it understands. That would also give an interface to generate ide-project files, since some people seem to like that, without having to integrate that into the build-system core.

So basically, we'd have a signal which passes all build information once it's available and an intrinsic target, `project-root`. And then you could just generate something from this:

json build-info : project-root ;
eclipse-xml .project : project-root::top-level ;

Now keep in mind: the system resolves everything before starting the first build, so the given code wouldn't be circular, even though it might seem that way.