Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-14 04:19:04

On Monday 13 December 2004 21:49, David Abrahams wrote:

> > Regarding the approach, I see two possibilities:
> > - do a progressive transition from bjam to Scons, keeping it working at
> > all times
> > - port everything from the ground up to Python until eventually it is
> > complete
> >
> > Just out of curiosity, I tried to port generators.jam to Python. It's
> > 40k worth of bjam code and I did it in afternoon, including some unit
> > tests and adapting the comments do Python doc strings.
> Nifty!
> Note that the algorithm used by generators.jam for calculating
> intermediate targets and build steps is not really general at all, but
> tuned for a specific case (Qt-related, I think -- .whl, .dlp, and .wd
> files are involved).

That's my own use case, actually.

> Related messages are in the threads at:,
> As a result I created a prototype of how the generator search *ought* to
> proceed... and it's written in Python! It lives in
> tools/build/v2/
> Unfortunately it's not trivial, but I think it represents the "right"
> logic from a conceptual standpoint. It has some significant comments,
> but could definitely use more.

I recall I had some concerns when you wrote it, but I only recently could
understand those concerns.

For quite some time, V2 had "generators priority" of some kind. When several
generators for a given type/property were viable, the priority was computed
and the generator with highest priority was selected. This did not work that

Say, there's are two RC -> OBJ generators, one general, and another specific
to msvc. So, you need to boost msvc generator priority. Suddenly, this
generator has higher priority that CPP -> OBJ generator, so the latter is
never used. You need to boost priority for CPP->OBJ too. This is becoming
very messy. So, currently there's an explicit way to say that generator 1 is
better that generator 2.

How is this related to your generator prototype? It tries to find the "best"
transformation from sources to targets by using some metric of the "best"
transformation. For example, path length. I recall there were some other
metrics too. But it's absolutely unobvious that this metric meets user
expectation in any way.

I think we need to treat any ambiguity as error, but allow the user to
disambiguate in some way.

Going back to .dlp/.whl/.wd use case, I think it would be better to ask the
user to provide direct .wd->.cpp generator, and don't try to automatically
compute the transformation via .dlp/.whl.

- Volodya


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at