Boost logo

Boost-Build :

From: vladimir_prus (ghost_at_[hidden])
Date: 2002-08-30 09:48:05

As soon as I started thinking about generators documentation, I've
run into some problems. I hope to get
some comments on them from as many people as possible (hint...)

To recall, our generator mechanism finds the transformation sequence
from sources to main target. For example, when building
a target of type EXE from a.cpp, the following sequence of actions
will be performed

A generator for EXE will be selected. It will try to convert a.cpp to
OBJ -- the only file it can directly handle. In order to convert,
another generator,
corresponding to compiler, and converting CPP to OBJ will be
selected. That generators will construct dependency graph for a.obj
and then
generator for EXE will construct a dependency graph for executable.

Imagine now that we have two source files, a.cpp and b.cpp. With the
current code, generator for EXE will handle those sources one by one.
That is,
it will first convert a.cpp to OBJ, then covert b.cpp to OBJ, and
then link em together. This approach works nice for a number of use
but there's another one.

In it, EXE will try to construct OBJ target from all the sources. In
order to do so, OBJ<-CPP generator will be selected. The generator
will be passed
*both* sources. It will pick one, say a.cpp, convert it to OBJ and
return. EXE generator will then try again, this time without a.cpp in
the list of sources.

What is the difference? The first approach is simpler to implement,
that's why it's implemented. However the second approach is,
theoretically, more powerfull.

R ----- 1.F ------ 1.Y ------ 1.X1
| \ \------- 1.X2
| \---------- 1.Z ----- 1.X3
| \------ 1.X4
\ ----- 2.F ------ 2.Y ------ 2.X1
\ \------- 2.X2
\---------- 2.Z ----- 2.X3
\------ 2.X4

This graph is no problem for make, but is impossible with our
approach. First, generator for R will break all sources apart.
Second, we never
considered target names. In this example, 1.X1 should be combined
with 1.X2 but not with 2.X2

We can try to support this kind of graph -- this has some
implementation problem but maybe they can be overcome. However, do we
need it?

1. The grouping of source target here is *implicit*. This is no
problem with make, because in it list of sources is implicit as well.
However, in Boost.Build
list of sources is explicit (a good thing, IMO), so why have implicit

2. Potential for confusion. Now, the meaning of a single source file
is the same, regardless of any other source files. If we allow such
graph, this will no
longer be true. Desirable? Consider UI transformation in m2-

CPP <--------- UI

I'd rather that UIC-H was always generated from UI, even if user adds
already generated UIC-H to the list of sources.

3. Not sure how usefull. There are cases when some grouping is
needed. Consider "my" example in m2-transformation.txt, where
marked.cpp is coupled
with positions file. I feel we can handle this by addining explicit
notion of target groups.

What do you think? Do we need to support this make-like graphs? Or
should I clarify my question?

- Volodya


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at