Björn Michaelsen wrote: > > - regarding parallelization, that's surely fixable with much less > > effort in build.pl, no? > Currently we are starting one dmake-process per directory and that > dmake process does paralellization the directory. Implementing a > recursive jobserver that communicates between dmake and build.pl would > not only be ugly, it would also be a major effort. > That's not what I meant. The reason to also hand over a specific dmake option for multi-processor builds is that sometimes only one or two directories have their actual dependencies satisfied & are thus buildable. So it would be ~trivial to only hand "-P16" over to build.pl, and let it distribute that across the active dmake instances.
> > - what kind of dependency tracking is missing in the current system? > Those that bite you on compatible builds. > Ah. That's what I thought. So nothing inherently missing in dmake/build.pl, but "just" bugs in the makefiles. > > - the question of correct dependencies is probably rather > > orthogonal to the question of which build system to use. much of > > the problems here are in modules like scp2, helpcontent, > > writerfilter etc. where tons of stuff is built via ad-hoc rules > > that simply don't get dependencies right. Having those handled in > > a declarative way would convince me a bit better, that a change > > in the build system actually addresses these issues - > > (see also Kay's > > http://blogs.sun.com/GullFOSS/entry/and_what_about_make) > We are using a declarative language -- also Kay knows what we are doing > and has contributed valuable input. I guess he would tell me, if I > tried something obviously wrong. ;-) > And yes, the build system to use is only "the color of the bikeshed", > but this is a chance to get rid of quite a bit of self-maintained > dependencies. As said elsewhere, the effort never aimed to simple > replace build.pl/dmake with GNU make for its own sake. > Sorry, but http://hg.services.openoffice.org/hg/cws/gnu_make/raw-file/2518db232510/sw/prj/target_lib_msword.mk then leaves a lot to be desired. There's still loads of redundancy - and actually, when compared to a dmake-style makefile without the carried-over cargo-cult contents - quite similar. > see my other replies here and on the blog. As a sidenote: project files > for common IDEs only give you more trouble, if they are one way (and > they currently all are): They are a just minor simplification for > newcomers for a simple build without changing anything. But I leave it > to you to explain to release engineers, why it is their job to translate > the changes made by a new dev in his IDE-project back to the cmake > source. They will rightfully refuse that. Thus the newcomer will have > to fiddle with the makefiles again manually, winning nothing in the end > (other than additional confusion and probably some needless > communication on mailing lists). > Yes. And? It's still significantly lowering the barrier of entry. Loads of other projects do it (with the same limitation). And the need to add a new file to the project is usually not the first, not the second, but the nth thing you do when starting to hack ... So stepping back a bit, I should probably mention (again) that I find the general idea really great - the make system is truly arcane & leaves a lot to desire. But despite your initial request for input, plans & thoughts, I cannot but have the impression you're already quite determined to follow the outlined route - sadly the build system has seen quite a few attempts for change; and survived all of them ~unmodified, thus some extra thought & consultation is surely advisable ... From my humble point of view, what has usually worked best in OOo land is some iterative approach to change; which in this case & my opinion would mean cleaning up makefiles one by one, either using a declarative DSL directly that could later be mapped to gnu make or whatever tool we see fit, or - using a meta-language like automake cmake, or something homegrown, *still* use dmake for the while, and then, after some critical mass has been attained, switch the make tool wholesale (and adapt the metalang-to-makefile generator). Additionally, and since you mentioned the desire to have only one make instance - last time someone tried to have gnu make hold all of OOo's dependency tree in one process, that guy (Kai Backman) ended up with absolutely pathetic performance & ridiculous mem usage. That's why he went for bjam ... Cheers, -- Thorsten
pgp2YkH7PTPIv.pgp
Description: PGP signature
