Hi Mathias, most of the points you've raised I already replied to in my followup to Bjoern (including my ideal msword lib makefile) -
Mathias Bauer wrote: > build.pl uses module dependencies, not target dependencies, so it has an > inherent susceptibility to bottlenecks. Basically all of our c++ sources > could be built in parallel (as they don't depend on each other), but > with build.pl we always have to wait until header files are "delivered" > or created. And because the dependency granularity level is the "module" > (not a real target like e.g. a library), we can't use as much > parallelization as possible. This becomes even more painful if you don't > build the whole office, but only some parts of it, e.g. in a split build > or if you rebuild several "modules". > Ah interesting - so we're then moving away from the solver concept? > No, really, there's nothing nailed until now. If you or anybody else > knew a better way and(!) offered help and cooperation, there's nothing > that would hold us back from doing it differently. > I find this "and(!)" slightly worrying - not that I would not lend a helping hand; but why are you refusing advise from people just because they may not have time helping you with coding? > > That's why he went for bjam ... > > Can you explain if bjam is able to fulfill the requirements Björn and I > have mentioned and what else it can do better than GNU make? Or can you > at least explain why you perhaps prefer it? > I didn't say I'd prefer it. I was just pointing to that project, and the experiences. Maybe it would help the discussion if more of the internal findings you mentioned would be public - come to think of it, maybe it would have been nice to have the whole discussion that led to this prototype public, in the first place ... ;) Cheers, -- Thorsten
pgpKhF392crUR.pgp
Description: PGP signature
