Caolan McNamara

Munster finally win the ERC. Ownership of bragging rights for the year/decade.

modularization
Been playing around with the idea of splitting the OOo build into two parts, the URE bits and everything else, FWIW the list of modules needed to build just the URE part of OOo (ignoring external modules) appears to be:

bridges        dmake             jvmfwk         sal        store
cli_ure        idlc              offapi         salhelper  udkapi
codemaker      instsetoo_native  offuh          scp2       ure
config_office  io                rdbmaker       solenv     xml2cmp
cppu           javaunohelper     registry       soltools
cppuhelper     jurt              remotebridges  stlport
cpputools      jvmaccess         ridljar        stoc

Mightn’t be too much work to build the rest of OOo on top of an separately installed URE and URE-devel set of packages, making a start into shrinking the bug update size for the long suffering FC OOo user

64bit
linux x86_64 OOo 2.0.3 is now building out of the box (with –disable-binfilter, binfilter fixes are in bfsixtyfour workspace), and available in rawhide now. Other 64bit archs should be able to build the common code, except for requiring uno bridge implementations, e.g. ppc64 should build as far as testtools.

Source for bridges is in bridges/source/cpp_uno/ and additional bridges can be shoved in there. Some small tweaks may be needed to get config_office/configure to generate an appropiate platform id for your platform, and a new platform .mk added in solenv, e.g. for the x86_64 ones see solenv/inc/unxlnxi.mk and the x86_64 entries in config_office/set_soenv.in

helpcontent2
With 48 languages, helpcontent2 in m169 is still heartbreakingly slow to generate all the helpcontent for the various languages, Free beer at Lyon OOoCon for anyone who knocks an hour off helpcontent2.

re gdb hatred: On the bright side the pending breakpoints (called deferred breakpoints at one stage IIRC) support in the latest couple of gdb releases works for me well thesedays.

Though I think you still have to have debugging information for the main containing binary available even to set pending breakpoints. Which is a little bit of a pity if you just want to debug one module, you have to rebuild with debug symbols desktop module as well as the one you’re interested in.

re unicode support: I added some dbg_dump functions to OOo which should be callable from gdb and gdb should be able to figure out the right one to call for the string class being examined. I’m not sure if this actually works anymore, it did at one stage with one gdb version, and then at another stage it stopped working, so it may have gone stale.

I made a little test-suite of gdb features scripts some years ago which tested some of those types of things, but the test-cases undoubtedly need reworking