Re: [Boost-build] [RFC] output events

Subject: Re: [Boost-build] [RFC] output events
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-02-25 14:49:17

Hi Aaron,

On 02/21/2015 08:44 AM, Aaron Boman wrote:
> Hi Vladimir
>
>  > Hi,
>  >
>  > I've checked in, on a branch, a patch that makes Python port emit
>  > JSON-formatted message describing what is being built, like so:
>  > ...
>  > The ultimate goal of this is to make it more easy for an IDE to see what's
>  > happening - in particular, some time ago Mateusz was asking for a way to
>  > discover include paths that Boost.Build uses, and there was no good answer.
>
>  From the commits I have seen in the server branch on github I think I understand what you're doing. However, just to be sure:
> What will an IDE be able to do once your idea is complete?

The minimum is:

- Ask Boost.Build to build particular targets with particular properties, and know which files were created
   with what ultimate properties
- Ask about list of features and their values, so that user that pick those in UI

Ideally:
- See how properties and build commands for individual targets change if one change top-level requested properties
- Be able to navigate entire dependency graph at metatarget level (i.e. why boost.system is requested with these
   properties)

Ultimately:
- Detect changes sources and do a very fast incremental build

> Will this allow the IDE to issue build commands that are piped into Boost.Build?

Yep. In fact, I've pushed a few commits to that effect over last couple days. So I can do this:

     echo '{"type": "request", "request": "build", "properties": {"variant": "release"}}' | b2 --python -a -d0 --server

and see the build actually happen.

> Do you have any plans to merge this capability with the daemon branch?

If time permits, yes. The daemon branch is not perfect, in particular because it uses DBus, which limits
itself to Linux, and is awkward to work with. However, it does have a lot of useful code that I hope to
merge into server branch.

> Most importantly, is there anything that I can do to help?

Thanks for the offer! It seems that the coolest bit would be incremental/daemon functionality, and that
seems like some work. There are actually two things:
- inotify support, to save work on build engine level
- caching results of metarget->target generation, which already works, but requires cleaning
   the cache if Jamfiles change, and I'm not entirely sure we do it entirely correctly

Is that something you'll be interested in?

Beyond that, there's a fair amount of possibly improvements to report what's happening, to
add help to key options, and so forth. I hope to have a test web-based UI using this API
deployed really soon now, and then it will be clearer what changes are desirable.

Thanks,

-- 
Vladimir Prus
http://vladimirprus.com