Hi,
as already discussed here, a team
(http://wiki.services.openoffice.org/wiki/Build_Environment_Effort) is
currently evaluating how we can
improve our build system. Björn Michaelsen presented a prototype for a
new build system based on GNU Make and we also have been pointed to
CMake by Jussi Pakkanen who already has investigated CMake as a
potential alternative for our build system. Björn continued to work on
his prototype and we also gathered some experience with CMake. My
special thanks goes to Martin Hollmichel, who wrote a considerable
amount of CMake make files (CMakelists.txt files) so that we could build
a bunch of OOo modules on Linux and Windows and see how it works and how
good it works for us.
A result of the investigations can be found in the wiki:
http://wiki.services.openoffice.org/wiki/Build_System_Analysis
I wanted to document all findings and considerations in detail. But this
is more than you probably will want to read ;-).
So here's an abstract of it. If you are interested in the details,
please read the wiki article.
As discussed on this list and in the blog
(http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu),
our current build systems has a lot of shortcomings.
We invested CMake and a new GNUMake based build system (let's call it
"GBuild" for now).
CMake - Plus
CMake solves the most important problem of our current build system: it
is able to guarantee a stable build. This means: if the dependencies in
the make files are correct, the build will work, if not, it will break.
[For those not in the know: our current build system may work even with
incorrect make files or break with them, depending on different boundary
conditions.]
An additional potential benefit of CMake is the option to export the
CMake makefiles into Visual Studio vcproj files (it is an export as the
heavy lifting still has to be done in the CMake make files). They would
allow to build the code in the IDE on Windows, though the performance of
the IDE when confronted with our project in total is something you need
to get used to, to say the least.
CMake - Minus
The major drawback of CMake is that we couldn't find a way to do the
conversion in separate steps. We had to write the CMake makefiles in
parallel to the existing ones and so had to maintain two build systems
for several months.
CMake does not overcome the other inherent faults of a recursive,
segmented build system that are explained in the wiki.
We also need a solution for builds from more than one code repository. I
explained that in the wiki. The "one project, one workdir" approach of
CMake does not offer enough flexibility to make that possible without
headaches.
CMake requires tedious procedures or extra scripting to easily build
single modules of OOo, something that is still important for many OOo
developers.
GBuild - Plus
The GBuild approach is able to guarantee stable builds but also to
overcome all problems of recursive make systems that are explained in
the wiki article.
It supports module based working and so has a very simple migration
path: every module can be converted one after another as the GNU Make
based system and the current one can be mixed, letting build.pl still
control the build, until all modules have been converted. We have
started with 8 modules for now (tools, svl, svtools, xmloff, toolkit,
sfx2, framework, sw).
The support for module based working also allows to easily setup a build
from several repos into a common output directory. So it doesn't matter
how our code will be organized in the future.
GBuild - Minus
The build system does not directly support building inside an IDE. If
the desire to build the code from inside the Visual Studio IDE on
Windows became overwhelming, we could adapt the GNU Make based build
system to the "external build" feature of Visual Studio, but this would
be an extra effort.
Additional remarks:
One might think that we had to write more stuff for GBuild than for
CMake that already has built-in support for some of the target types we
have in OOo. OTOH our current prototype already covers C/C++ compiling
and linking. Everything else we still have to work on has to be
implemented with custom targets in CMake anyway and so we can't get
anything important directly (means: without writing our own macros and
rules) from CMake that would require more hacking with GNUMake.
By using the powerful GNUMake language we could implement some high
level concepts provided as macros. These macros made it possible to work
without explicitly specified dependencies in the user make files as they
already enforce the correct behavior from the specified targets and
prerequisites. We couldn't find a way how to do that with CMake as it
lacks the necessary features in its language.
Conclusion:
GBuild has more Plus and less Minus than CMake. Especially the missing
migration path is a showstopper. So we (the team mentioned above) will
continue with our GBuild approach and aim to make that the new future
build system for OOo. Thanks to all who gave us their input, and we
would be glad if this will continue in the future.
We would be glad to see other interested developers join us. We will
need the cooperation of the developers interested in the ports that we
don't do in Hamburg. To my knowledge this is mingw, OS/2, FreeBSD,
MacPPC. As all use gcc, the porting effort is expected to be very small.
A port to Solaris for what we have implemented so far (building C++ and
C libraries and executables, compiling resource (rsc) files and sdi
files) took only a few days. Most probably a port to another platform
using gcc will be much simpler.
Björn will keep you posted on the proceedings we have made in the last
weeks and those that will follow in the future.
Best regards,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamfor...@gmx.de".
I use it for the OOo lists and only rarely read other mails sent to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
