Build Environment Effort/New Build System Requirements

From Apache OpenOffice Wiki
Jump to: navigation, search

Edit.png

Build Environment Effort

Quick Navigation

About this template


Introduction

This page lists the requirements for a new build system for OpenOffice.org. In addition, it discusses how easy or hard these aims are achievable with different alternatives. The general feasibility is taken for granted for now. Investigations about that must consider what we are currently building. A reference can be found here.

Build Configuration

  • Current build system (autoconf): Autoconf is a huge old mess, but it has lean deps (POSIX sh) as long as there are no needs to change the configuration. A huge part of the configuration is custom code and not standard autoconf macros.
  • GNU make: GNU make does not provide a configuration tool itself. So one would continue to use autoconf or another configuration system.
  • cmake: CMake provides tools to check the configuration of the build system, but since OOo uses only a few standard checks, a lot of code would need to be rewritten.

Lean dependencies

To ensure a long life and maximum portability (even to platforms that might not even be available yet) for the new build system it should depend on as little as possible.

  • Current build system (build.pl and dmake): The current build system has fat dependencies. It depends directly on Perl and dmake (which has to be maintained by OOo development). In addition a wide range of tools are being used: zip, awk, GNU coreutils, GNU findutils, ant (please add more ...)
  • GNU make: GNU make is lean in its direct dependencies -- it is part of the GNU toolchain and thus available on all platforms where gcc is available.
  • cmake: CMake aims to be highly portable, but it is not usually available on the default install of many platforms. Also it does not build itself, but requires another native build system to be available on the platform for that task (GNU make on unix).

Debugging

  • Current build system (build.pl and dmake): The current build system is not easy to debug because its code is old and the used tools are too adding needless complexity (Perl, dmake).
  • GNU make: The new implementation is very clean. It should be a lot easier to debug and use for common developers.
  • cmake: CMakes BuildLists are clean and well documentented. CMake generates native build system files. Failures in the generated makefiles might be a lot harder to track down to their source.

"Native" Builds on Windows (msbuild)

  • Current build system (build.pl and dmake): The current build system does not provide a native Windows build using msbuild.
  • GNU make: It is not very hard to generate msbuild files from GNU make for common build tasks. However, there are many cases where the current build process depends on a large set of external tools like bash, awk, findutils, coreutils. Doing a "native" build that requires cygwin and a wide range of other tools does make little sense.
  • cmake: CMake provides native builds for common tasks. However, there are many cases where the current build process depends on a large set of external tools like bash, awk, findutils, coreutils. Doing a "native" build that requires cygwin and a wide range of other tools does make little sense. cmakes ability to generate msbuild files for common build tasks only solves a part of the problem as a "native build" that requires a lot of external tools has little to no added value.
Documentation note.png One might consider using Python as a tool for _all_ non-standard build tasks. Python is easy to distribute and install on all platforms. However, it is also a very fat dependency and thus it is questionable, if it would be worth the effort just to get rid of cygwin (or another Unix environment on windows).

Dependency generation

  • Current build system (build.pl and dmake): The current build system uses a set of mostly redundant dependency generators: a selfmaintained mkdepend, a selfmaintained rscdep ...
  • GNU make: The GNU make prototype uses the dependency generator of the compiler where possible. On platforms, where these are not available, a externally maintained generator is considered for use (mcpp was the first choice, but might be to slow as it does very thorough syntax checks)
  • cmake: CMake has its own dependency generation. It has to be checked, if that generator can be used for all deps needed in OOo build (resource files etc.)

Parallelization

  • Current build system (build.pl and dmake): The current build system uses a two-step approach (build.pl starts one dmake process per directory). Its a bit like a recursive make system limited to depth two. However, build.pl and dmake do not even communicate the number of running processes (like a GNU make would do with its jobserver).
  • cmake: The common approach with CMake is also to use recursive makefiles (one per library). This hinders paralellization in that object files of a library are not compiled (although compilable) unless all libs that are linked against are completely linked (although those are only required at linktime).
  • GNU make: The GNU make prototype handles all deps in one process and thus can compile all object files ASAP.

Code Quality

  • Current build system (build.pl and dmake): very low - quite often ad-hoc, procedural coding of tasks.
  • GNU make: The GNU make prototype employs a declarative way of specifying tasks, but commonly violates the DRY principle.
  • cmake: CMake has a reasonably brief and declarative syntax.
  • GNU make + custom generator: see GNU make, enforces declarativeness, eliminates the boilerplate. Also, additional constraints can be expressed.
Documentation note.png There are a few things to consider when discussing a custom generator: Will it introduce new deps? Is it possible to use GNU make, the C Preprocessor or POSIX sh for translation, and require heavier deps (like Python) only for validation? That would allow the build deps to be kept lean, while still allowing the goals of enforced declarativeness and eliminated boilerplate.
Personal tools