Re: [jamboost] Building the dependency graph

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

David Abrahams wrote:
> This message is concerned with building the dependency graph. That job
> includes the generation of intermediate targets (e.g. when building an exe
> from sources, the object files are intermediate) and the invoking of rules
> which establish dependency relationships and build actions.

1. Why do we need hierarchy? Aren't all transformation between leaf vertices 
in it? (I see dotted line from "object" to "LIB" on your graph. Do you really 
mean that LIBS can be assembled in yet another library)

2. What is your definition of "toolset"? You say: 
"build jobs outside the domain of the toolset". For me, toolset is nothing 
but a named set of transformation rules.

3 My proposal on building semantics (still on the Wiki) differs from yours in 
that I have all the dotted edges (or transformations, or actions) annotated 
with requirements. If requirements are not met, path search simply won't 
consider that transformation. To consider you example with C++ fronend 
compiler:

exe foo : foo.cpp ;

There might be the following transformations available 

type->type : requirements : rule
C++->OBJ : <toolset>gcc : gcc-C++-compile
C++->C : <toolset>auc : auc-C++-compile
C->OBJ : <toolset>aux : auc-C-compile

Therefore, transformations for both gcc and auc can be found. To elaborate 
futher, we should assume that every rule given to toolset is deterministic: 
it performs all the transformation in which it's mentioned. Then, suppose we 
have to deal with g++'s template repositories (e.g. to clean them)

C++->RPO : <toolset>gcc <template-repository>on : gcc-C++-compile ;

Now it's easy for the build system to notice that when gcc-C++-compile is 
invoked and template repository is used, one more file will be created. 
Lex/Yacc seem simple as well:

LEX->C : : lex-generate 

There's a question, though: how will the set of subvariants will be computed. 
One option is too specify features that are relevant to each target type. But 
then, relevant features specific to toolset won't work. I'd prefer simply 
considering all the alternative pathes, which can be used to generate a 
target, and to generate subvariants based on that information.

Then there're combining actions like Archive and Link. I don't think allowing 
them inside implicitly generated transformation is needed or feasible. Then, 
they always should generated using explicit main targets. It should also be 
insured that path search algorithm don't accidentially pick those 
transformations. In all the other respects, they can work in a similar fashion

EXE<-OBJ,LIB : <toolset>gcc <runtime-link>static : gcc-link
EXE<-OBJ,LIB : <toolset>gcc <runtime-link>dynamic : gcc-link
EXE<-OBJ,LIB : <toolset>aux : aux-link

(Actaully, there should be both "required requirements" and "relevant 
requirements" on transformation, to avoid writing all possible values of 
relevant features, but this is a detail).

With all said, I don't think we should look for shortest path to find 
transformation sequence -- we should look for unique one. 

How does this sound?

- Volodya