Thorsten Behrens wrote: > 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?
This is irrelevant for the system in question. With or without solver, you will have the same problems with our current build system. The only thing that matters is how many modules you want to build in parallel. > >> 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? Did I say that we would refuse advise if it clearly showed improvements? Of course not, why should we? But I wouldn't call "don't use X, Z is much better" an advise. Or, to say it with Monty Python: "This is not an argument, this is contradiction." "No, it isn't!" "Yes it is!" etc. etc. Perhaps I should rephrase my statement: the best I can see is that people show us that what we want to achieve by using GNU make can be done even better, simpler, faster etc. in a way we don't know until now and help us to get that implemented. As far as I'm concerned, the second part is optional, but of course much desired. >> > 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. Just pointing to a project without giving a hint how that could solve the problems isn't very helpful ATM (though I appreciate the hint and surely will have a look when I have some time). So if you could explain how bjam (or any other make system that someone wants to suggest here) solves our problems or why the problems that require bjam to be resolved are even bigger than those we try to fix, we might be able to get somewhere. > 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 ... ;) You can find most of our findings, discussions etc. in the wiki (I have posted the link several times) or in Björn's and my blogs. Björn also will post some more data about GNU make investigations soon. They never were planned to be "internal findings", but posting them without prior explanation wouldn't have made sense and even now they don't add anything to the discussion we wanted to start. The topic is not "can GNU make do that", but "do we have the right goals" and "GNU make can reach the goals, which other tools can do it also or perhaps even better". Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
