Re: Boost.Build and SCons

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-14 09:10:33

Vladimir Prus wrote:
> On Monday 13 December 2004 21:49, David Abrahams wrote:
> 
>> 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.

"Hand-tuned" weighting schemes never work. You very quickly end up with
an unmaintainable hodge-podge of rather arbitrary choices. In many ways
it is like the arbitrary choices I perceive in the current generator
choice heuristic.

> How is this related to your generator prototype? 

Not at all.

> It tries to find the "best" 
> transformation from sources to targets by using some metric of the "best" 
> transformation. For example, path length. 

Yes. There's one, simple, objective measure: "how many build steps does
it take to get from here to there?"

> I recall there were some other 
> metrics too. But it's absolutely unobvious that this metric meets user 
> expectation in any way. 

Really? If you had a bunch of tools that could make various
transformations and you asked it to turn your .foo file into a .html
file, wouldn't you expect the system to take the simplest possible route
by default? Imagine there's a one or two step path and a ten step path.
Wouldn't you be mad if the system reported an ambiguity and forced you
to resolve it? I would.

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

I can't find the message right now, but I distinctly recall that we
_agreed_ that your particular case automatic computation of that
transformation is the wrong thing to do, because the particular sequence
of steps you want isn't minimal by any measure.

http://article.gmane.org/gmane.comp.lib.boost.build/2803

is another such example.
-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com