Re: [jamboost] Generators vs. Make

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-30 10:28:35

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

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

I'm not convinced that it's neccessary to be able to automatically deduce
target grouping from the source target names involved. Are there any
examples of this sort of thing in the real world?

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

Good question.

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

The graph is certainly possible in our current scheme, just not implcitly.
IOW, there would have to be an explicit main target for 1.F, 2.F, 1.Y, 1.Z,
2.Y, and 2.Z.

I don't think that's a serious limitation.

-Dave