Re: [Boost-build] The future of B2?

Subject: Re: [Boost-build] The future of B2?
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-10-05 05:07:04

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