Re: [jamboost] Eureka?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-17 05:44:46

David Abrahams wrote:

> > Them, why you say:
> > "In other words, we
> > choose the shortest path from sources to targets"
> > Do you implicitly assume that the transformation chain will contain only
> > (one source, one target) rules?
>
> No, I just shouldn't have said it.

Then, why minimum number of targets means shortest path?

> > > This would be easy if we searched from source to target. I am reluctant
> > > to do that, however, because even though there are many generators of 
> > > OBJ products, I fear that many more might be able to match a source
> > > type,

> > A! Actually, I was always considereing search from sources! I though
> > search in the opposite direction was an idea you only recently got.
>
> I don't remember how it happened. I do think starting with sources is more
> natural in many ways.

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 
to exe. 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. (*)

This should work nice except for two problems.
First is ambiguiity:
Should WHL->CPP or DLP->CPP transformation be selected when EXE<-OBJ and
OBJ<-CPP are found? I think that all the transformation should return the 
list of intermediate transformation that they cause. In this case, the list 
of transformation will be the same, and we can see that no ambiguity actually 
exists.
Second is how rules are selected in general:
It is possible to use the method you propose, counting also the targets 
produced in (*) step. 
It is possible to count the number of transformations on each alternative.

What would you say?

> > > Ah! I remember what I thought about this: it might not be so bad to ask
> > > people to write something like this for these cases:
> > >
> > > exe foo : @asm ;
> > > wd asm : asm.wd ;
> > >
> > > This is an easy way out.
> >
> > This is an easy way out, but... wouldn't it require wd rule to be ad-hoc
> > one, i.e. wouldn't it simple create conversion sequence explicitly, again
> > bypassing the general scheme?
>
> No, sorry, I wasn't clear. The product of wd is .cpp files. Not ad-hoc at
> all. in fact, if you wanted just the lexer .cpp product from wd, you might
> write:
>
> exe foo : @asm.lex
>

But how wd rules will work? Will it create the whole transformation sequence 
or call matching for <target_type>WHL and <target_type>DLP. In the latter 
case, care should be taken not to run WD->{WHL,DLP} transformation twice.

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?

- Volodya