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,
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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk