Build System Improvements

From Apache OpenOffice Wiki
Revision as of 12:34, 15 January 2015 by Adailton (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Yet another build system improvement

This is not the first attempt to improve the build system of OpenOffice. There has been at least ( What can we learn from this?

Don't change everything at once
Use a step by step migration where each step improves the build system even when following steps will never be made.
Use the right tools
GNU make is not the right tool for object oriented programming. The build logic of OpenOffice is apparently complex. Express it in a suitable language.


Ultimate goals

  • All modules are built with the same make tool, instead of dmake and gbuild today.
  • Creation of installation sets is driven by the same system that builds the other modules.
  • Libraries and other files that will eventually find their way into an installation set are created in their final place. Today these files are copied several times.
  • Building becomes faster on Windows.
  • Buildings becomes fool proof, i.e. after a change you can make a full build with minimal overhead for unmodified files (today an empty build takes several minuts).
  • The build system is documented and maintainable.

Low level goals

  • Global file dependencies
This allows a central makefile to parallelize the build much better than with the current per-module or per-directory dependencies. It removes the need to explicitly state dependencies between directories or modules. Start up time of make becomes longer because a large number of dependencies have to be read. Alternatives to make like ninja can do this much faster.

Short term goals

  • Convert build files to single file format.
  • Convert a large part of the dmake and gbuild files to plain makefiles.

Move the build logic from makefiles (in solenv/inc and solenv/gbuild) to the transformations. This might already be enough to build a large part of OpenOffice with global file dependencies.

How to get there

In several smaller steps which are detailed in following sections:

File format conversion
Change the file format of all files that drive the build process to a single format. The transition to other build tools would become much easier when the se files where expressing in one single and well documented file format. With such a format we could provide transformations into the file format of the new tools. It would become easier to make experiments with alternatives to make like cmake, gradle or ninja when all we have to do is write a simple transformation into the input format of these tools.
File format conversion steps (note that each file format conversion includes a script to transform back to the current format):
  1. build.lst
  2. gbuild makefiles
  3. dmake makefiles
  • skip scp2 because that would be too much work
  • skip makefiles in main for now, they will become obsolete when is replaced
Replace with a generated makefile
Partial conversion from dmake to make
Evaluate whether it is feasible to make partial conversions of dmake directories to Gnu make.


File Format Conversion

The different file formats that are currently used by the build system are:

  • <module>/prj/build.lst
The per-module and inter-module dependencies for
  • <module>/<directory>/
The per-directory dmake makefiles.
  • <module>/Makefile and <module>/*.mk
The per-module gbuild makefiles.
  • main/*
Configuration file with values from initial configure run.
  • main/scp2/**/*.scp
Declaration of which files go into installation sets.
  • main/ and main/Makefile
Shortcuts to build --all or make clean.

Replace with center makefile

Creating a makefile that builds all module (in the right order and in parallel) is is the easy part. The hard part is to provide the many features of See a previous evaluation of which features to keep and which to drop [here] Provide shell functions for convenience:

  • Find the central makefile
  • Determine the module to which the current directory belongs.
  • Process arguments and pass them to make and the central makefile.

(Partial) conversion from dmake to make

Factor out the parts that are easy to convert and frequently used (compile C++ files and link them to libraries) and keep the rest in dmake files. If this works then the migration from old to new build system would become much easier.

Personal tools