Re: [jamboost] Eureka?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-17 08:54:37

David Abrahams wrote:
> I've been trying to get you to forget that I ever said "shortest path", but
> if you want to think of it informally, the shortest total length of all
> paths combined will yield the fewest intermediate targets.

Ot! It is very, very similar to "minimal number of involed transformations" 
that I've been talking about.

>
> > Let me see.
> > 1. If we search from sources, we loose the abiliby to run specialized
> > generators according to properties, right? Well, no -- we still can run
> > actions on the top-level target, which actions can adjust properties. We
> > loose the ability to modify properties and run code for intermidiate
>
> targets
>
> > only. I have no idea if this is a problem.
> >
> > We might also have a performance hit, but probably it's not important:
> > results of seach can be somehow cached.
> >
> > Ah, almost forgot to explain how search from sources can work. Exactly as
>
> you
>
> > written in your previous message -- we'd need to keep related target
> > together, so the pathes found will look like:
> > WD -> {DLP,WHL} -> {LEX,CPP} -> {CPP,OBJ} -> {OBJ,OBJ}
> >
> > 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. 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.

> > > > > exe foo : @asm ;
> > > > > wd asm : asm.wd ;
> > >
> > > exe foo : @asm.lex
> >
> > But how wd rules will work? Will it create the whole transformation
> > sequence

> The wd rule is analgous to "dll". It knows that it generates multiple
> targets (a DLP and a WHL). It may also give you an abstract way of
> referring to one of those targets by itself (the WHL, via "@asm.lex") in
> case you want to link directly to that file. 

Okay.

> I would be unhappy with any
> arrangement that /forced/ a target to depend on all products of any source
> file, just because it depends on a single one. This is the only way I can
> see to give the user some control when she wants to the result of a
> multi-product generator.

Agree.

> > What @asm.lex syntax means? I'm starting to thing that we'd need a way to
> > specify nested target creation, like this:
> >
> > exe foo : foo.cpp nm_as.wd->LEX
> >
> > It could mean to run matching using <target_type>LEX and nm_asm.wd as the
> > list of sources, and then add targets to source list of "foo". Is
> > @asm.lex meant for the same purpose?
>
> ooh, too complicated!

Not sure again.

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

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.

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

- Volodya