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
>> 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.
"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
> 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.
is another such example.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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