Difference between revisions of "Build Environment Effort/New Build System Requirements"
From Apache OpenOffice Wiki
B michaelsen (Talk | contribs) (Created page with '{{Build Environment Effort}} __TOC__ == Introduction == This page lists the requirements for a new build system for OpenOffice.org. In addition, it discusses how easy or hard th…') |
B michaelsen (Talk | contribs) |
||
| Line 7: | Line 7: | ||
== Build Configuration == | == 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. | * '''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. | + | * '''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. | * '''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. | ||
| Line 21: | Line 21: | ||
* '''cmake''': CMake generates native build system files. Bugs in the generated makefiles might be a lot harder to track down to their source. | * '''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. | ||
| + | {{Documentation/Note|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.) | ||
Revision as of 11:15, 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 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.)
