Re: [jamboost] Eureka?

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

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
To: <jamboost_at_[hidden]>
Sent: Thursday, January 17, 2002 5:44 AM
Subject: Re: [jamboost] Eureka?

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

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.

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

Very complicated. So far I opt for the easy way out:

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

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

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

I hope I can convince you that simple is best, here

-D