Re: [jamboost] Eureka?

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-17 09:43:08

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

> > > 2. If we search from targets, then there's a problem we've discussed a
> > > message ago: multiple targets in intermediate rules that should all be
> >
> > linked
> >
> > > I think a have an idea how it can be addressed. Suppose you
> > > consider
> > > generators for <target_type>CPP
> > > - WHL -> CPP transformation is found
> > > - WD -> WHL transformation is found
> > > - WHL->CPP transformation, which initialted the search that found
> > > WD->WHL, asks that transformation about any other files it produce
that
> > > should be processed, DLP is returned.
> > > - WHL->CPP transformation tries to match transformation from DLP to
the
> > > top-level target type. (*)
> > >
> > > [snip]
> > Very complicated. So far I opt for the easy way out:
>
> Is it that complicated? I've only added one extra step, which is quite
> simple.

Oh, I envisioned something complicated when you wrote "tries to match". What
does that mean, anyway?
Also, does it handle the case where WHL->LEX->CPP and DLP->CPP?
Finally, does it force the products of wd to be handled as a unit?

> Selection rules are almost the same as you've proposed, and the only
> non-trivial thing is finding equivalent alternatives, which is quite easy
> once the list of all intermidiate transformation is collected.

What do you mean by "finding equivalent alternatives"? Please spell it out
for me.

> > I hope I can convince you that simple is best, here
>
> Hmm... we have two questions:
>
> 1. Do we finally settle on target-to-sources scheme and abandon BFS
starting
> from sources?. What rationale should be given if anybody asks?

It's the best we could think of?
All build systems seem to proceed from targets to their dependencies?
Show us how to make it work well the other way?

For most people, the search direction will be an implementation detail. If
something better comes along, I'm happy to consider changing the
implementation. What's important to me is that it handles the cases we can
think of in a fairly general way.

> 2. Could you consider my proposed extension to generator matching for some
> more time? I think that it's not that complicated and will give certain
> benefits. On the other hand, it handles not the most baseline case and can
be
> added at a later time.

I'd need some more explanation.

> And then... hope we'll start writing something!

HERE HERE!

-Dave