Difference between revisions of "Build Environment Effort/New Build System Requirements"
From Apache OpenOffice Wiki
B michaelsen (Talk | contribs) |
B michaelsen (Talk | contribs) m |
||
| Line 12: | Line 12: | ||
== Lean dependencies == | == 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. | 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 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 ...) | + | * '''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. | * '''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 (GNU make on unix). | * '''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 (GNU make on unix). | ||
| Line 31: | Line 31: | ||
* '''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) | * '''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.) | * '''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 recursive makefiles. | ||
| + | * '''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. | ||
Revision as of 11:22, 1 February 2010
Contents
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 (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: CMake generates native build system files. Bugs 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 very small 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 recursive makefiles.
- 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.
