Re: [jamboost] Re: Generators vs. Make

From: David Abrahams (dave_at_[hidden])
Date: 2002-09-02 11:09:22

From: "vladimir_prus" <ghost_at_[hidden]>

> > > 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?
> 
> I haven't seen any. So, if anybody here knows real world example,
> please speak out!

I really think this is a case of "explicit is better than implicit"
This could be done as

build-r R : 
[ build-f 1.f : [ build-y 1.y : 1.x1 1.x2 ]
[ build-z 1.z : 1.x3 1.x4 ] 
]

[ build-f 2.f : [ build-y 2.y : 2.x1 2.x2 ]
[ build-z 2.z : 2.x3 2.x4 ] 
]
;

> We agree so far. Hope we won't run into problem later.
> I'd have to implement some grouping of targets to support my
> use case in m2-transformations.txt, but that grouping will be 
> explicit and won't depend on
> names.

Sounds good to me.

-Dave

-----------------------------------------------------------
David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com