Re: [jamboost] Re: Boost.Build and SCons

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: http://tinyurl.com/68xc4,
> http://tinyurl.com/5axa5
>
> 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/generators_prototype.py
>
> 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 
nice.

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