Build Environment Effort/Dependencies

The taming of the shrew

A current build contains roughly 200 "modules", top level directories in the repository. Our build system tracks build dependencies between them in the "build.lst" files in the "prj" directories of them. Not every tracked dependency is necessary or useful, some dependencies have been forgotten, some were never correct, some can be avoided by a few code or makefile changes. This is tracked in issue 103496.

If all dependencies are drawn in a module graph, the result Media:Complete.odg is hilarious and chaotic, due to the fact that at both ends of the graph some modules collect a lot of dependencies. At the lower end it's solenv as this is needed always and at the upper end it's postprocess as it "depends" on every module that without postprocess would be a top level module. The module instsetoo_native and smoketestoo_native depend on postprocess. By removing these modules as well as dmake and guw (as they are built outside the ooo build process) the graph Media:reduced.odg looks a bit better, but it's still too much as especially the indirect dependencies make it impossible to see the forest for the trees.

It should be possible to group modules, either by their "level" in our project or because they are somewhat related. Some of the mentioned unnecessary or bad dependencies prevent a proper separation between the groups, so fixing that by moving or changing source code is necessary. Here's a suggested group list, based on the DEV300_m51 build and the fixes from issue 103496 applied. I have created the groups so that their modules basically should have dependencies only on each other or to modules from a "lower" group. In some cases there are some dependencies that violate that principle, but I'm confident that they can be fixed by changing code or module content. Issue 103496 or any follow-up issues will track that progress.

External modules

These comprises the following modules: afms, agg, apache-commons, berkeleydb, bitstream_vera_fonts, boost, cairo, cppunit, curl, epm, expat, external, fondu, hsqldb, hunspell, hyphen, icc, icu, jfreereport, jpeg, libegg, libtextcat, libwpd, libxml2, libxmlsec, libxslt, lpsolve, lucene, MathMLDTD, moz, msfontextract, neon, np_sdk, openssl, python, redland, rhino, saxon, stax, stlport, tomcat, vigra, xpdf, xsltml, zlib.

With a single exception (agg) all code modules are checked in as download + patch, "external" contains binary stuff that is not part of the repository. After fixing the dependencies there's only one "bad" dependency left, cppunit depends on sal. This is still subject to investigation.

URE - UNO Runtime Environment

In former times we even have built this as a separate product, but nowadays it's only a part of the ODK (OpenOffice.org Development Kit). All parts of the URE only depend on each other or on some external modules (so that a packaged URE could need some of them, e.g. stlport). Some dependencies have been fixed. A packaged URE would need a license file that currently would create a build dependency on readlicense_oo. Though no localized license files would be needed, the fact that readlicense_oo also does the localization would create a dependency on the localization tooling. This must be fixed anyway, so I have omitted that for the moment and so readlicense_oo is not a part of the URE list:

bridges, cli_ure, codemaker, cppu, cppuhelper, cpputools, idlc, io, javaunohelper, jurt, jvmaccess, jvmfwk, offapi, offuh, pyuno, rdbmaker, registry, remotebridges, ridljar, sal, salhelper, soltools, stoc, store, udkapi, unoil, ure, (ure_top,) xml2cmp

I have added pyuno though it never was or currently also not is part of the URE, but it feels like being a part of it. "ure_top" is a hypothetical URE top level module that contains all dependencies to URE modules that are currently in postprocess. It could be seen as a possible future module for packaging the URE.

The list contains offuh and offapi as currently the only way to generate UNO API headers is using offuh. As soon as we replace offuh by building headers inside of offapi and udkapi, we can remove offuh and offapi. The former would just go away, while the latter would become a part of the next group:

ODK - OpenOffice.org Development Kit

This group currently comprises only one module: odk. Here all parts of an ODK installation set are collected in some zip files that will be used to create an installation set in instsetoo_native. Some dependencies need to be fixed. In future this group also may contain offapi, as explained in the URE section.

The ODK currently uses GNU make (and some tools from the URE) for builds, while the OOo build system uses build.pl and dmake. It would be nice to have both systems united, so that not only all extensions but also OOo could be built with an ODK. The future will show how and how fast we can achieve that.

Build and test tools

Beside build.pl, dmake and the URE/ODK build tools some other tools are needed to build OOo. To my knowledge this comprises the following modules:

autodoc, udm, cosv, idl, qadevOOo, rsc, soltools, testshl2, testtools, transex3 (udm and cosv are modules that only autodoc uses, so I have added them here).

They should depend only on external or URE modules. Currently that isn't true, mainly due to a dependency on "tools".

Some special modules

Before we come to the "real thing", here are some modules that don't fit well into any other categorie. Some of them deliver parts of an OOo installation set:

crashrep, extras, helpcontent2, l10n, readlicense_oo

while some don't:

migrationanalysis, soldep, testautomation

I've put them aside for now. IMHO all of them except crashrep and readlicense_oo are good candidates for separate source code repositories.

Images

All images in OOo will be packed into images.zip. This requires the modules

default_images, external_images, ooo_custom_images, packimages

With the exception of packimages no other modules should get images directly from the images modules.

Extensions

Some modules are built as extensions:

dictionaries, sdext, swext

They still contain some "bad" dependencies (e.g. dictionaries on readlicense_oo), but that can be fixed. Building extensions should not require anything than an ODK.

Office modules

Everything else can be seen as an "Office" module. It can be helpful to differentiate between "top level" modules (those who don't have others depending on them) and "basis" modules. Some modules are "real" UNO components have only very low level dependencies (URE and external) or are close to that (only dependencies on e.g. tools and comphelper), others have dependencies on the usual suspects (vcl, svx ...).

Top Level modules

accessibility, automation, basctl, bean, beanshell, binfilter, chart2, desktop, dtrans, embeddedobj, embedserv, eventattacher, extensions, forms, hwpfilter, javainstaller2, lingucomponent, oovbaapi, package, padmin, psprint_config, reportbuilder, reportdesign, sane, sc, scaddins, sccomp, scp2, scripting, sd, slideshow, starmath, sw, twain, UnoControls, unodevtools, unoxml, wizards, writerfilter, xmlsecurity, xmerge

Some of them might be tools (still under investigation). Some modules are not top level but have only one top level module as "customer" (e.g. extensions that depends on sane and twain), so I added them here.

Basis Office modules

animations, apple_remote, avmedia, basebmp, basegfx, basic, canvas, comphelper, configmgr, connectivity, cppcanvas, dbaccess, drawinglayer, fileaccess, filter, formula, fpicker, framework, goodies, i18npool, i18nutil, linguistic, o3tl, officecfg, oox, regexp, sandbox, sax, setup_native, sfx2, shell, sj2, sot, svtools, svx, sysui, toolkit, tools, ucb, ucbhelper, unixODBC, unotools, uui, vcl, vos, writerperfect, x11_extensions, xmlhelp, xmloff, xmlscript

The goal for these modules should be to combine some of them to few and larger ones (and rearranging the code in them).