at Oracle - goals - general approach - wind of change - other topics • Status Quo of the Build System - architecture, problems and scalability - a way to do it better? • GNU Make Build System
as simple as possible, but not simpler.” It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience. – "On the Method of Theoretical Physics" The Herbert Spencer Lecture, delivered at Oxford (10 June 1933)
friendly build experience by making building OOo less complex, stable and faster • Concrete goals: – Improve the build performance – Make the build reliable even for non-experts – Better support for execution of tests in the build – Create runnable office in the build
influence each other. If something shall be fixed, consider all options: • Fix the build environment • Fix the code • Optimize cooperation by fixing both
Fix DLL_IMPLEMENTATION usage • Fix tools requiring backslashes in cmd line • Reduce number of library naming schemas • Separate internal and delivered headers • Rethink registration process for UNO libraries • Get rid of delivered static libraries/object files • Get rid of stlport • ... Build Environment Effort: Wind of Change
OpenOffice.org: – build.pl / deliver – dmake • dmake works more or less like any other make tool • build.pl iterates over “modules” and directories and starts dmake processes • build.pl learns about dependencies by “build.lst” files • deliver copies module output into the “solver” Current Build System: Architecture
“compatible builds” • Cargo cult programming in makefiles • Source tree is not read-only • Lots and lots of process instantiations • Too many tools for the same job • Maintenance of “homegrown” tools Current Build System: Problems
not limit found • Number of rules: problems start at ~10000 rules Solution: Use pattern rules • Command line limits not hit until now – Cygwin ~ 1MB However, link.exe is quite picky about long command lines. solution: responsefiles – Linux ~ 100 KB (depending on stack limit) • GNU Make internal limits: only limited by amount of RAM
per build • One makefile per deliverable • Single, complete dependency tree • Using eval/call for declarative description of targets • Target local variables • GObject-like OOP in GNU Make
SRCDIR – WORKDIR – OUTDIR • One all including makefile • One makefile per module for “compatible builds” • C/C++ is organized around the “link targets” GNU Make Build System: Architecture
against the link target • build its objects • generate dependencies GNU Make Build System: Architecture Objects depend on the header targets of the targets: • they are part of • they link against Link targets are the final result (i.e. a library)
directory: – GNUMakefile – Module_ooo.mk – SourcePath.mk – Targetnames.mk • In the solenv/gbuild directory: – gbuild.mk for bootstrapping the build system – one file for each type of target (for example: library) – the platform subdirectory with platform dependent content • In the solenv/doc directory: – Files to generate gbuild docs with doxygen
Migrate modulewise • Keep build.pl at top level • Dmake just calls GNU Make Then replace build.pl: • Use GNU Make instead • No more two stage build • Single build process • All dependencies in one process
as much platforms as possible – especially all those linux flavors, MinGW etc. • Options: – optimizing for ccache (separate dep generation) – “hard build order” – dependency generation on linking – mixed debug/non-debug builds • Dependency generation with MSVC • Build Configuration • distcc/ccache • Migration Tooling: makefile generator etc.
Ause Lankenau, Heiner Richtien of Hamburg RelEng and Mathias Bauer • Kay Ramme, Thorsten Behrens and Matthias Huetsch for architectural discussions • Jussi Pakkanen and Martin Hollmichel for work on CMake prototyping • the [email protected] mailing list