Caolan McNamara

Output of sloccount on the fedora OOo pre-build unpacked OOo, i.e. basically the sloccount of OOo minus the external modules otherwise normally found in the cross-distro build like libxml2/mozilla/libwpd/etc and some redundant modules which don’t contribute to the final office deliverables, e.g. autodoc/odk/qadevOOo. So it’s a lower-bound count of OOo. Summary comes to 4,670,779 lines.

Totals grouped by language (dominant language first):
cpp:        4282359 (91.68%)
java:        198542 (4.25%)
ansic:        95936 (2.05%)
perl:         58905 (1.26%)
sh:           13242 (0.28%)
yacc:          6828 (0.15%)
cs:            5018 (0.11%)
python:        3353 (0.07%)
lex:           2474 (0.05%)
asm:           2436 (0.05%)
lisp:           804 (0.02%)
awk:            692 (0.01%)
php:            104 (0.00%)
csh:             79 (0.00%)
sed:              7 (0.00%)

1. libxslt01 (ready for qa) would introduce the libxslt module into OOo, pending sun legal work to make it into OOo
2. If that goes ahead then libxslt02 (created and ready to roll post libxslt01) builds on this to
   1. make the collection of xsltproc patches and alternative targets the default and replace the current selection of java based tooling for officecfg, readlicence_oo and filter, etc. Unifying the more or less default external community build defaults with that of Sun’s internal ones, and giving a speed boost for officecfg building
   2. replace the runtime usage of sablot with that of libxslt. Shrinks the size of OOo a little for the system-using world, and seating us on a more contemporary solution.
3. nativehelplinker (#i70155) would then also build on libxslt01 to replace the XmlSearch and java helplinker programs with a native libxslt/libxml2 using app giving a significant speed boost for building the multiple language helpcontent2 help files, it might be interesting at that stage to take stock and see if xt.jar is then still used by anything.
4. nativehelplinker would remove the need for db4-java, so bumping the internal db4 to a later version of db4 and dropping building db4-java becomes easier. That would hoover up some of those outstanding db4 upgrade patches for xmlhelp that are floating around