On Fri, 2011-03-18 at 16:44 +0100, Thorsten Behrens wrote:
> Merging from OpenOffice.org's DEV300 code line
Soo ... I guess I wanted to say a few thoughts on this, and what was
learned in the process.
Firstly - apologies; there are almost certainly bugs introduced as a
result of the merge: both human errors, and machine merging ones - these
are hard to avoid, and after six straight hours of reading and deciding
on patch fragments, it is possible to get quite tired.
Ergo - if you're chasing a bug; it can be useful to look at the code
versions on both ooo/DEV300_m101 and also the
LO-BASE-INTEGRATION-DEV300_M101 tag.
Similarly, if you have done your best to remove all the random 'OD'
style comments from writer - there are now some more :-) Similarly, I
imagine most dead-code cleanup tasks, and cppcheck runs and so on will
sprout yet more interesting fruit; so please be patient. It is a also
possible that one or two fixes have been missed: please test your pet
features.
Apart from that - I think we learned a few things:
* whitespace changes just for the sake of it, are a
PITA to resolve
* re-sorting enumerations, or esthetic line re-ordering is
also not ideal :-)
Of course, some work is inevitable - we translated a ton of German
comments, on lines that then had type changes, leading to a lot of this:
A: BOOL bSaveState; // whether we should save the state
B: sal_Bool bSaveState; // Ich bin ein berliner
Or somesuch ;-) in future we may need to do more automation of such
changes, and/or merge smaller chunks.
There are a few known regressions; help on these much appreciated (cf.
Thorsten's mail), eg. fixing the About dialog.
Another problem is that the gnumake build system tends to copy
libraries around instead of hard-linking; which rather increases the
build tree size: my build is 18Gb small [ though I have a few extra
pieces lying around ], that is slightly up from the previous 17.5Gb or
so. Fixing solenv/gmake/Deliver.mk to use cp -l and fallback to cp -a if
that is not possible may improve things there.
Otherwise - we got a number of really nice wins here.
In particular Stephan Bergman's work binning the slow, bulky and
unusable services registration code - in favour of an XML services.rdb
(same name sadly) should help kick-start our cross-compiling to Windows
- which should help to further accelerate our build process.
Of course, introducing the gnumake build system, gives us a lot of work
that can be turned into easy hacks, turning each of our modules into
gnumake enabled ones: eventually yielding a single 'make' command that
can incrementally re-compile only the files necessary, and quickly too
(as well as compiling 1000 wide or somesuch) :-) Some great work from
Bjoern / Mathias Bauer there.
There are a lot of other things too, but - these were the pieces that
bit me off the bat doing some of the work here.
Thanks !
Michael.
--
michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
