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:
> 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
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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk