Re: [jamboost] Re: cool generators insight

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-04 05:37:41

David Abrahams wrote:

> > The question is:
> > what if to produce type A from source of type B, you need to produce D1
> > from B, produce D1 from B
>
> You just said the same thing twice.

Sorry. Produce D1 from B and produce D2 from B.

> > and then link them together --- and you cannot link this D1 with D2
> > from some other source.
>
> I think you'll have to clarify that one.

I meant that if you have "1.d1", "1.d2", "2.d1" and "2.d2", you cannot link
"1.d1" and "2.d2".

> >> I am convinced that's the
> >> right way to treat sources. My search states contain, essentially, a
> >> multiset of sources which need to be consumed and another multiset of
> >> targets which have been produced.
> >
> > Hmm.. the produced targets must be consumed as well, until you get to the
> > final target type? Then, what the difference between source targets and
> > produced targets?
>
> As far as the search is concerned, nothing, except that all the
> original sources must be consumed in order to reach a goal state.

There's a gotcha. When using shared libraries on Windows and you write

exe hello : hello.cpp lib ;

you get two targets for "lib": shared library and import library. You can 
consume only one of them. 

> > Also: multiset of sources or multiset of source types?
>
> The latter.

The latter or the latter plus the number of targets of each type?

> > I've a question here. Why ambiguity means there's no point in exploring
> > the path. Doesn't it mean we have to issue an error right away?
>
> No, another path may reach the goal unambiguously. It's just that the
> branch that's dying would be guaranteed to be ambiguous even if it
> succeeded in producing a goal state. If all the paths to the goal
> pass through that state, then there will be an error.

So, if another path reaches the goal unambiguously, you don't care about 
ambiguity in some other search node? Hmm.. I can't understand this.

> It is only viable if there area exactly one of each of those two
> types in the source multiset.

What about "1.d1", "1.d2", "2.d1" and "2.d2" mix I've described above?
You have two targets of type D1 and two targets of type D2.

> > Good luck. I'll try to prepare a certain use case. It is based on
> > asm->static_data->cpp one which we've discussed on Jabber, but has yet
> > another target type to mud the water.

The use case is now in "m2-transormations.txt" file. Here it is for 
convenience:

EST.EXE <---- OBJ* <----------------------------------------- CPP
^
| 
+--------------------- CPP <---+------------NM_ ASM
| |
+- CPP <------ STATIC_DATA* <--+
| STATIC_DATA ^
| | 
| | 
| NM_ASM <--- CPP <---------- ECPP
+--------------------------- CPP <-+

NM.EXE <---- NM_OBJ * <-------- NM_ASM <------ CPP 
<-------- NM_ASM 

Note: all STATIC_DATA files produced from sources are linked together
to create one CPP and one STATIC_DATA file. 

The messy thing about this is that in first graph, "NM_ASM" target type is 
processed in two different ways. Moreover, the first graph should use
NM_ASM <- CPP generator when processing ECPP sources, but should not apply
it to NM_ASM sources, preferring {CPP,STATIC_DATA)<-NM_ASM generator.

- Volodya