Hi Jussi, you might have noticed that your suggestion to replace the whole build system has met a bit of skepticism here and there. Please don't let this discourage you. Just let me explain why this is so:
- at some point in the OOo history there were proposals and efforts to replace the OOo dmake with gmake, ant and lately jam. None of these efforts went very far. - the scope of such a task is, well, daunting. If you search for makefile.mk (DEV300 m41) you'll see 2284 instances of makefile.mk. Add a few differently named global makefiles this makes a whopping 2300 or so to be converted makefiles, give or take. Any conversion must be assisted with an automated process, that much is clear. http://svn.services.openoffice.org/opengrok/search?q=&defs=&refs=&path=makefile.mk&hist=&project=%2FDEV300_m41 - the major part of OOo is written in C++ but we've got a number of other languages in there from C, Java, Objective-C++, AWK, Perl, Python, several IDLs etc. I've yet to find a Fortran source in OOo :-) - a number of tools have to be integrated as well, resource compiler, idl compiler, localization tools, packaging etc. - we've got any number of special cases, these things just tend to grow over the years. Redoing them with CMake won't be easy but then, a thorough clean up would be a Good Thing (TM). - most of the time is spend in compilation and things like help content. Speeding up the build system will be greatly valued but it must be considered how much effort in redoing the build system is justified by a, say, 10% increase in build speed. For 50% we'll do a lot :-) - it might not immediately meet the eye but the current build system allows for two kind of parallelism: - concurrent build on a target in a makefile.mk - concurrent build on a inter-directory level Both are used extensively and some will hate it if their favorite kind of parallel build goes. The current dmake process is not optimal but it works and is well known to the OOo developers. New developers might know CMake better than dmake but if this is the overuling criteria we should switch to gmake (no, I'm not proposing this). I'm very much for improving the build system and think this might even be best done by a radical new approach. But I would hate to see another good approach is wasted just because the task is underestimated. This should by no means discourage anyone from evaluating better methods, we need them, but is just a reminder that if such a huge change is to be going real some serious developer buy in is needed. Heiner Jussi Pakkanen wrote: > On Mon, Feb 16, 2009 at 3:39 PM, Thorsten Behrens <[email protected]> wrote: > >> I guess that slightly misses the point, as I believe Jussi also >> proposes getting rid of the build.pl/dmake marriage, plus much of >> the hard-coded, non-declarative stuff in the makefiles. > > Yes, this is precisely what I had in mind. Sorry if I was not clear on > that in my earlier messages. Replacing dmake with CMake while keeping > build.pl would of course be a total waste of effort. > > I'll try to get sw compiled with CMake and do some measurements. Then > we can talk about hard cold facts rather than estimates. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Jens-Heiner Rechtien [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
