Build Environment Effort/Module Problems

From Apache OpenOffice Wiki
Jump to: navigation, search


Build Environment Effort

Quick Navigation

About this template

default_images, external_images, ooo_custom_images

These sub modules contain a lot of small binary files and they will blow up every repository they are in. So it would be nice to have them in a separate repository. Currently it is not possible to build any module containing image list resources as the rsc compiler always checks whether the referenced images are present. This should be avoided as it will be checked in packimages anyway and as this is not a unit test of the resource but an integration test for the product, this seems to be just the right time.

testing related stuff

In “testautomation” stuff for the automatic testing is included (test scripts, test documents). This clearly should be moved into an own repository. “testtools” contains some integration tests not meant to be run in the build. The same is true for smoketestoo_native. It should be kept in the “build prerequisites” repository together with instsetoo_native, packimages, postprocess, dmake, soltools, solenv and the root of our current repository (that includes configure). “automation” contains both the testtool and the library linked into OOo. Perhaps it's possible to split that as only the latter part is needed to build OOo. Otherwise the “automation” sub module must be moved into the “framework” module. In case qadevooo or testtools shall be used inside the build it could be moved into "ure" or “odk”, "testtools" perhaps should become integrated into the modules it tests.


This module contains two sub modules that have stl code that currently uses stlport and so has a dependency on the “extern” module. As soltools is a part of the build system that shouldn't have any dependencies against any of the modules it shall build, the problem must be fixed by using the compiler stl when building soltools.

apache-commons, tomcat

This sub-module was added to the “extern” module because we needed https support in the MediaWiki extension but meanwhile we have that in the UCB and so we are going to replace the usage of apache-commons and tomcat in the MediaWiki extension. We have to find out which parts of apache-commons and tomcat are used elsewhere and if we have to keep them.


In the OOo build environment developers have to download either the source or zipped binaries that will be unpacked to use Mozilla based functionality in OOo. In the SO build environment a different module called “moz_prebuilt” is used – an unfortunate difference. The biggest problem is that on Windows building from source is not possible as they can't be built with a newer compiler than MSVC++ 2003. If that can't be changed it would be the best if we could get rid of moz completely. This would require to find a replacement for ldap and Mozilla/TB address book support that is currently based on “moz”.


Instead of using CppUnit “as is” we have added a lot of code to “improve” it. The worst thing is that this code depends on sal, so that it is impossible to run the unit tests of sal while building it. To be able to run at least all other unit tests of the URE libraries, I have added testshl2 to the “ure” module. It should be dropped completely and all unit tests should be changed to use the latest version of cppunit.


Configuration files could bee seen as “content” and so may be a candidate for an own repository. On the other hand odds are high that developers have to change files in it more than occasionally so it makes sense to keep it in the lowest possible module where configuration files might be used. Some higher modules currently use the DTD of our configuration schema for xml processing. If we can't get rid of that maybe the DTD could be moved into the ODK as that would allow extension developers to use it without needing to download and build the “common” module or use its development package (as extensions shouldn't use anything “above” the odk).


Currently only Calc uses the vba stuff, but probably in future this will be used for other applications as well, so putting it into the calc module does not look wise. The question remains whether it should stay in the “common” module or if sooner or later it will need to use GUI or even framework or svx code so that perhaps we should move it “upwards” in the module hierarchy.


The license files deliverd by this sub-module are needed everywhere where a “product” is created. Currently this comprises the Office itself, the ODK and all extensions that don't have own license files (like the dictionaries). While the first two products are created in instsetoo_native, the extensions are built in their own module and so this module will depend on readlicense_oo and thus on the module it is put in. Currently the best choice seems to be the “odk” module as this would allow us to create OOo extensions without requiring any othe modules than extern, ure and odk. We have to find out if having readlicense_oo in “odk” will create problems for the localization process that treats the readlicense_oo sub-module in a rather strange way.


This extension uses code from the “common” module. As the code is linked statically or is inline, there is no runtime dependency created so the extension can be seen as compliant to the requirement not to use “office” libraries at runtime. On the other hand this build dependency is rather unfortunate and might open a way to let office code slip in silently. This problem should be solved explicitly, not by silently ignoring it.

components module(done)

I have used a separate module for all top level sub modules that don't depend on system or GUI stuff, but most probably they should be merged with the “common” module into a common code repository as that would still be fine from a code size and build time POV and allows more flexibility in the future. Some sub modules might be candidates for a different treatment.


Though the build dependencies don't require it, this sub module perhaps fits better into the “GUI” module as it provides toolkit based controls. I wonder whether someone uses them at all...


“xmerge” contains code for an optional filter. Depending on how optional filters shall be treated it might be moved elsewhere.


This sub module provides clipboard support and probably is a candidate to be moved either into the “GUI” module or the “system/deployment” module. The current build dependencies will allow to do both but we should find out what makes the most sense.

svtools (done)

svtools contain too much different stuff and so can't be assigned to a group easily. Some content surely belongs to “GUI” as it depends on vcl, but other content better fits into the “common” module group. So we should split that up before we split the repository.


sysui currently has a dependency on setup_native, without “” sysui throws errors while packing Debian menus for broffice. That should be investigated.


It is very probable that this modules no longer will depend on GUI libraries when the svtools library has been split up accordingly, so it can be moved into the “common” module.

shell (done)

This sub module depends on vcl, most probably just because it includes a convenience header for the kde headers from there. This should be fixed as “shell” clearly belongs into “common”.


The quickstarter is implemented in sfx2 and this adds a dependency on “setup_native”. This should be fixed in any way so that no other sub modules except “desktop” will depend on “system/deployment” anymore. Some parts of sfx2 should be moved into the framework sub module or into the “low level” svtools part in “common”.

xmloff (done)

It also links against svtools, but also against vcl. The reason for the latter is symbol font conversion and the definition of some enums. It should be possible to move this from vcl to tools.

linguistic, lingucomponent (done)

“linguistic” uses some sfx based code to open streams. This can be fixed easily and it can be moved to “common”. “lingucomponent” depends on linguistic and svtools. Probably after fixing linguistic and splitting of svtools it can be moved into “common” also. The dependency of linguistic on xmloff will be an additional problem in case we can't get vcl out of xmloff.


Currently some code based on graphic filters from svtools is used here. It can easily be replaced by an UNO API based implementation and so the sub module can be moved into “common”.


The code for our own file dialog still is in svtools; it should be moved here. It's unfortunate that the testtool application uses an imagelist from “fpicker” so that it depends on the “framework” module and that sounds a bit strange.

svx, goodies, sfx2, svtools(ongoing, first step done)

These modules are candidates for a complete redesign. Depending on the outcome some rearrangements of depending sub modules may be possible. First step done:

  • moved svx/source/cui and related header and resource files into own module "cui"
  • move svx/source/msfilter and svx/source/svdraw/svdfppt.cxx and related header files into filter/source/msfilter and add some loadoncall magic to files in other libraries that currently link against this code (except the code in the msfilter libraries or the sc,sd and sw modules that of course still link against libmsfilter but are loadoncall by themselves).

formula, xmlsecurity, scripting

It would be interesting to investigate if “core” and “ui” in “formula” can be separated so that parts can be moved into “common”. But maybe this is not worth the effort and also comes at a price if code changes in both parts are necessary at the same time. Similar considerations can be applied to xmlsecurity and scripting.

desktop, extensions

These sub modules also need a redesign as they contain a lot of different stuff that partially can be distributed to other modules. “extensions” might be removeable completely this way (in my tentative diagram I assume it will be), “desktop” will stay as the application that will require GUI and framework functionality anyway. Depending on how we can redesign it it can be moved into “system/deployment” or “framework”. In my diagram I denote these parts as “application” and “desktop”. The dependencies on sfx2 and svx in “desktop” can (and should) be removed easily.

filter, hwpfilter

We will have to decide where to put these sub modules, depending on how we will treat optional filters. Packagers might want to have them separated.

Personal tools