Re: [jamboost] Eureka?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-15 04:52:49

David Abrahams wrote:

> > I'm in opposition again :-) Please see the parallel post, where I
> > talk about subvariants and relevant properties.
>
> What is your concern about property relevance? The only thing it gets
> used for is determining target location.

Because it also determinies the exact set of targets that are build and I 
think it's important that boost system don't do any unnecessary actions.

> > Are you sure this is good enough criteria? There's only one example
> > of using optional properties in your email, and I'm not unsure about
> > it.
>
> What do you mean by "I'm not unsure about it?"

Either "not" or "un" should not have been left.

> These criteria handles things like target-type specificity. Properties
> in an inheritance/refinement hierarchy can be composite properties
> which expand to add properties for all of their bases. So for example,
>
> <target=type>PYD
>
> might expand to
>
> <target-type>PYD <target-type-base>PYD
> <target-type-base>DLL <target-type-base>executable
>
> (see http://groups.yahoo.com/group/jamboost/message/88 if you need to
> refer to the target-type refinement hierarchy). A generator which
> wanted to match all executables might specify
>
> <target-type-base>executable

Say there another generator, with
<target-type-base>DLL 

Clearly, if you want to build PYD and no specific generator specific to PYD 
is present, generator for DLL should be selected. How will it be given 
precedence over <target-type-base>executable. Or do you plan to always have 
default generator for each type, which generator will simply change target 
type to that of parent and invoke the matching process once again?

> > I don't fully understand. Do you mean <source-type> is needed to
> > match the last transformation?
>
> Actually, no. I realize I didn't explain this fully. <source-type> is
> there as an optimization for the case CPP->OBJ. Any time you can cause
> a more-specific generator match you can avoid potentially-expensive
> search through other generators (e.g. a PASCAL->OBJ generator).

I see. And we can work without <source-type>, by means of selecting the 
generator with the less nonzero number of targets, right?

> This requires a small modification to the procedure I outlined
> earlier. I thought we might need this anyway: after generating
> these "targets" (just objects so far, not targets in the core Jam
> sense), we recurse through the dependency graph and generate the
> real targets and build actions.

Yes, this is needed, I think.

> I wonder if this handles things like STLPort. Hmm, let's see: we want
> the STLPort executable generator to be invoked preferentially to any
> one toolset's generator. This generator will add <sysinclude> paths,
> etc., to the build request, then re-invoke the process to generate the
> executable.
>
> We can add
>
> <toolset> <target-type>EXE <target-type>DLL <target-type>IMPLIB
> <target-type>LIB
>
> to its optional properties, and <target-type-base>executable to its
> required properties. That should suffice.

This is kind of magic to me :-) If you'll have another generator with 
required properties <toolset>gcc <target-type-base>executable, then will 
STLPort generator be selected becuse of extra <target-type> match?

> How does that sound?

This starts to sound more attractive than before.

Let me try some use cases. 

1. STLPort
Suppose we want <stdlib> property. Will STLport executable generator have to 
consult the value of this property? If there's another standard library 
STLnonport, will generator for it have to consult the property as well. If 
there two generators (from STLport and STLnonport), which one will be 
selected? I presume we can't run both?

2. Consider my favourite transformation sequence:
asm.wd -> asm_parser.whl, asm_parser.dlp
asm_parser.whl -> asm_parser.cpp
asm_parser.dlp -> asm_parser.cpp

Both cpp a then compiled and linked.
exe foo : asm.wd ;

When searching for transformations, the will be two pathes leading to asm.wd. 
We'd need, during second pass (which computes targets &c), to make sure 
transformation from wd to whl and dlp won't be run two times.

3. What would you say about the idea of having special executable kind called 
'unit-test-EXE', which will do almost the same as 'EXE' but will run the 
executable. Looks like all that is needed to the define transformation with 
<target-type>unit-test-EXE? 

So far I don't see any problem. I'm still unsure about the matching 
algorithm. Can we insure that any particular transformation will be run 
first? Can poorly written transformation take precedence just because it has 
a long set of optinal properties. Won't it be easy to create such a incorrect 
transformation by mistake? I don't have any examples, but it scares me a 
little.

- Volodya