Re: [jamboost] Re: cool generators insight

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-05 09:16:55

David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> >> Vladimir Prus <ghost_at_[hidden]> writes:
> >> > {CPP,CPP} <- ECPP (only first CPP must be further converted into
> >> > NM_ASM)
> >>
> >> How is that not an automatic ambiguity?
> >
> > I don't know what's "automatic ambiguity". I don't see anything wrong
> > about processing the first file in a different way from the second.
>
> They're the same type. How can you expect the generator process to
> deduce that the first one should be converted to NM_ASM and the
> second one should not, instead of doing it the other way? You've
> given no information to indicate which file to choose for that
> transformation.

Hmm... the first one should be converted to NM_ASM. The generator should 
produce targets in fixed order, I believe.

>
> >> You might get around that by generating a derived type of CPP,
> >> e.g. NM_CPP, which can be converted into NM_ASM.
> >
> > Say, I write
> >
> > nm_exe foo : foo.cpp ;
> >
> > Here's "foo.cpp" is of type CPP, and it should be converted into NM_ASM.
> > Writing
> >
> > nm_exe foo : foo.nm_cpp
> >
> > is not that nice.
>
> It seems to me that your case is one which cannot be automatically
> solved without ambiguity.

I realize it's not the easiest case to deal with. However, it must be dealt 
with something. For example NM_OBJ <- NM_ASM transformation can be 
disabled when creatin EST_EXE target (using generator requirements)

The case with NM_ASM <- CPP <- ECPP is harder. I'd really like to reuse the 
NM_ASM <- CPP transformation already defined. It could be possible to 
specify that STATIC_DATA <- NM_ASM <- CPP chain is usable only when processing 
target of ECPP type and main target type is EST.EXE.

Not sure if this fits in your algorithm, though. Do you have any proposals, 
except for making types CPP_2, NM_ASM_2 and adding NM_ASM_2 <- CPP_2 
transoframtion?

- Volodya