Generators vs. Make

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

Hi
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 
cases,
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.
Consider

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 
grouping.

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-
transformation.

CPP <--------- UI
\---UIC-H---/

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