Build Environment Effort/New Build System Requirements

Build Environment Effort
Quick Navigation Customers Build Performance Elimination of Non-Pro Dependencies Module Problems Split Build Scalability HID List New Build System Requirements External Source Tarballs ToDo Build System Analysis Zen of gbuild Gbuild Bootstrapping Module Migration Module Migration Tips Build System Analysis:capstone2013 windows build Capstone 2013 Client Requirements Document Capstone 2013 Technology Review & Implementation Document
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 archiveable with different alternatives.

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.

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.)

Paraellization

• 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.