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).
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
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.