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
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?
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