Re: [jamboost] Building the dependency graph

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-14 11:51:28

Vladimir Prus wrote:
> David Abrahams wrote:

> There is a question of what happens is a single action generates
> several targets. I don't know the right answer yet.

I don't see a problem.

> > Conversely, I don't like the idea of generating multiple build
> > variants just because the toolsets support a certain kind of
> > variation. Normally, a user will just want a release build, and a
> > developer will just want a debug build. One build.
> 
> I tend to agree now.

Cool.

> > I think it's reasonable to say this:
> >
> > * the user gives us a set of property combinations (s)he wants
> > * we do some magic to expand the specified properties. This may
> > include:
> > * expansion of compound properties
> > * executing rules associated with executable properties
> > * There is a procedure for running generators based on each
> > property set.

> > This procedure should support a kind of overload resolution which
> > allows us to control precedence based on specificity. This part is
> > complicated and I'd rather have a simpler alternative, but I don't
> > see one now. * generators are run to build the dependency graph
> 
> What bothers me about your suggestion is that it seems to attempt to
> guess all the build variants by looking only at top-level target,
> before finding transformation. How can we account for the fact that
> some intermediate transformation depends on value of some feature?
> How can we handle the possibility that intermediate targets can have
> fewer relevant properties than top-level target. I don't necessary
> mean that your approach precludes it, but would like to see a way to
> address those questions.

Let me clarify. I haven't really dealt with subvariants in any of my
messages yet. They don't have as much importance in my vision of the
new system; after all, they're not very well-defined. I think of a
subvariant as a target+build properties+built file location,
nebulously.

When generating a top-level target, we have the expanded build request
which results in a collection of property sets. For any given property
set:

1. Match generators by the process outlined earlier. No, there is no
opportunity for intermediate generators to affect generator
selection for targets at higher levels

2. invoke the generator for the target. 

3. The generator may choose to
add or remove properties which affect the actual build at this
point.

4. The generator determines target location

5. The generator generates its intermediate targets, if any (usually
by invoking the generator matching process again). Inherited build
properties are passed down the dependency graph from target to
sources.

6. Synthesized build properties are passed up the dependency graph to
the main target from its sources and/or intermediate targets

7. The generator generates the final targets and invokes build
actions.

Does this leave you with any questions?

> > What does it mean for a target type to "have" a
> > transformation. Can you make this concrete for me?
> 
> It means that the tranformation has a type as either source or
> target type. Lately I considered a possibility considering first
> pathes from source to target types, and then (if no path is found),
> to walk up&down the hierarchy, and searching pathes between target
> types which are not exact match. We'd need to discuss your proposal
> before turning to this one, though (I find it slightly more
> complicated that it should be)

Yeah, that scares me. We'd have to be careful not to loop forever.

-Dave