Re: [jamboost] Eureka?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-15 11:35:23

David Abrahams wrote:
David Abrahams wrote:

> > > 4. VIRTUAL TARGET SELECTION
> > > ======= ====== =========
> > >
> > > In this step, we select one of the dependency graphs generated by a
> > > generator in the generator set. The criterion is simple: we choose the
> > > graph whose generator returned the shortest list of targets.
> >
> > Could you clarify: do you mean the minimum number of generated targets
>
> (seems
>
> > like you've meant that before,
>
> Yes.
>
> > or am I misreading you mail?), or minimum
> > depth of the dependency graph?
>
> No. It should be rephrased to say "the fewest number of intermediate
> targets", period.

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?

> > Why can't both whl -> cpp and dlp -> cpp tranformation be considered. Or
> > either one can be prefered to another, randomly?
>
> Let me spell it out:
> We find the generator for EXEs. That initiates a search for generators of
> OBJ/LIB, and finds CPP->OBJ. That initiates a search for generators of CPP
> and finds one of those two transformations from whl/dlp. It doesn't matter
> which.
> ...um okay, I see that we see the same problem...
>
> > > It is always possible to
> > > register highly-specialized generators which know about both their
> > > source and target types, and which can guide the process in between. 
> > > So we might have a generator which can deal with .whl,.dlp->.o*, for 
> > > example.
> >
> > And it will be a generator with requirements (<target-type>OBJ
> > <source-type>WD), which will just create a predefined graph. What I don't
> > like here is that we abandom the general scheme -- we just specify what
> > to do with particular source file type.
>
> I agree. What's the basic problem here?
> It's that the transformation ASM->WHL,DLP has expanded the number of
> ultimately linkable products. Other rules which generate multiple products
> like OBJ->DLL,IMPLIB don't have the same effect. It's more than that, even:
> it's that the executable wants ALL of the products of a wd. I can easily
> imagine a case where the multiple products should be linked into different
> final targets. Something has to know what it means to have wd in a source
> list.
>
> Hmm, let's try this: Give the knowledge to the generator for WD->WHL,DLP
>
> Take the example where we don't have DLP->CPP, but DLP->LEX->CPP, so we
> have a path-length mismatch. I claim we want the search graph to look like
> a straight line for each source file, so we need to use sets of target
> types (I don't mean to suggest this must be a BFS):
>
> WD -> {DLP,WHL} -> {LEX,CPP} -> {CPP,OBJ} -> {OBJ,OBJ}
>
> We need sets of source files because something has to know that they are
> kept together

Looks so, indeed.

> 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, e.g.
> TEXT.

A! Actually, I was always considereing search from sources! I though search 
in the opposite direction was an idea you only recently got.

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

> Another possibility is that we search from source to the final target's
> input types, and rely on properties like <target-type> to guide the search.
> So if there were a source type with many different products, its generators
> would tend to declare optional properties which encourage it to be
> preferred.

As I've said previously, I have no clear understading how this case with be 
handled with BFS starting at sources. I'll think about it. 

> Well, sure, that's fine. I don't see anything wrong with a rule for tests
> which is like (glossing over details):
>
> rule test ( name : sources + )
> {
> output-file $(name).results : @name.exe ;
> user-target $(name) : $(name.results) ;
> exe name.exe : $(sources) ;
> }
>
> In other words, not everything needs to use the fancy search mechanism.

Okay, I'm guilty of overgeneralization :-)

> Let me know what you think about taking the easy way out. Please also
> consider the bottom-up BFS. For most source types, there are only a few
> transformations.

Okay, I'll post futher opinions as soon as they're ready. Meanwhile, it seems 
that we've agreed on all the other matters.

- Volodya