Re: [jamboost] Eureka?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-14 10:55:18

David Abrahams wrote:
> On building the dependency tree, I think I see what to do.

FWIW, I don't think it's 'tree'. One source file can easily generate two cpp 
which need to be compiled and linked.

> Building a target from sources goes like this:
>
> construct a set of build properties by expanding the build property set

I'm in opposition again :-) Please see the parallel post, where I talk about 
subvariants and relevant properties.

> find G, the set of generators which match the build property set
> remove all but the "most-specific" matches from G
> find the generator in G which would generate the least nonzero number
> of targets
> invoke that generator to build the dependency graph for the target

> For this procedure to work, generators clearly have to be more than just
> functions: they should be "objects" of some kind, probably based on the new
> class.jam module. 

I agree, of cause.

> Generators will be chosen based on a set of build properties. A generator's
> matching criteria are composed of 3 lists:
>
> required-properties
> optional-properties
> rules
>
> A generator doesn't match unless all of its required-properties match
> The matching process for a generator looks like this:
>
> local match ;
> if $(required-properties) in $(build-properties)
> {
> match = $(required-properties)
> [ set.intersection optional-properties $(build-properties) ] ;
> for local r in $(rules)
> {
> match = [ $(r) $(match) ] ; # maybe some other arguments, too
> }
> }
> return match ;
>
> The specificity of a match is given by the length of its match list.
> Basically, generators that match more properties will be more likely to be
> chosen.

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.

> TARGET CALCULATION
>
> The generator will have a function which returns the targets it would
> produce when satisfying a build request. To produce this list it may well
> invoke the matching and target calculation process again on some or all of
> the source files, with the build property set changed to reflect the
> generator's input target types. 

So, you in effect ask generator to explicitly run next step of graph search? 

> For example, a generator for executables
> comes across a CPP file in a list of sources. It then replaces target types
> in the build request with its list of input target types (OBJ LIB,...). The
> matching process finds a generator which matches <target-type>OBJ with
> optional <source-type>CPP. This generator, if eventually selected, is the
> one that invokes the C++ compiler.

> Why is CPP an <source-type>CPP an optional property for the C++ compiler?
> Consider what happens when a a YPP source file appears in the list of
> sources: the C++ generator should still be matched - it will want to invoke
> the matching process itself once again, hopefully finding a generator which
> matches <target-type>CPP/<source-type>YPP.

I don't fully understand. Do you mean <source-type> is needed to match the 
last transformation? Do you envision that top-level generator will be invoked 
with the list of all the sources, and that all the others will recieve only 
one item in list of sources? 

I'm not sure what I think yet. One thing is that you allow to get control 
over generation of any target type. This is good. However, I hasn't yet got a 
feel of how this fill work in contrived examples. 

- Volodya