On 05/11/2010 09:54 AM, Konstantin Tokarev wrote:
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.
Your conclusion is wrong. See add_custom_target function in manual -
you can run any external build system from cmake. I even use it as
configurer which founds OOo binaries and jars for ant :)
This is not the way we can do it: we need it the other way around - plug
CMake into our current build system. Otherwise we had to rewrite our
current build system before we can use CMake. Plugging CMake into our
build system means that each module must be buildable separately. To my
understanding this means to have a "root" CMakeLists.txt for every
module. When the conversion is done, we had to change that again as then
we want to have CMake control the whole build.
We didn't see a way to achieve that with a bearable effort. Do you know
one? Until we have converted all "modules" in our build system, a new
build system would have to support the "compatible mode" of building,
means: don't build anything outside of the module (as build.pl decides
when to build which module). This will of course go away when the
conversion is complete.
This is not a fault of CMake, but it is a consequence of the totally
different approaches of our current build system and of CMake.
As for me, major advantages of CMake are:
* speed of initial configuration step, fast re-configuration because of
caching;
* easy setting up of build parameters through ccmake - much more
convenient than those --long-keys;
* more intelligent tracking of source dependencies - less files require
rebuild if something changes than autotools think;
* possibility of parallel build of several directories;
* much faster installation - up-to-date binaries are not updated
Also:
* it's easy to determine operating system of build host and do custom
actions for each platform (e.g., build bundle for Mac)
CMake does not overcome the other inherent faults of a recursive,
segmented build system that are explained in the wiki.
Again wrong. You can use add_custom_dependencies for each module and
configure build oreder as fine as you need
Please read the wiki article, it seems you don't know which "other
inherent faults" I'm talking about. Recursive systems have *inherent*
disadvantages and overcoming them needs to switch to a non-recursive
system. This is not related to dependencies. CMake has a non-recursive
element (the export to the backends), so everything that can be
evaluated here (dependencies) can be done without the disadvantages of a
recursive build system. But the build itself is recursive, so everything
that happens at build time shows the usual disadvantages as described 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.
Wrong. You can add paths from underlaying dirs into CMakeLists.txt, or
even use ../ to get higher... Nobody forces you to have CMakeLists.txt
in every directory, and you can run external build systems for
sub-directories with passing them correct parameters
Again you didn't understand what I was talking about. I didn't write
that this is impossible, but it's not as easy as with our own approach.
The goal is to have makefiles of sub units that can be combined with
each other so that they produce output in the same workdir. In our
GNUMake based approach all you have to do for that is include the
makefiles of the parts you want to combine, whereever they reside. In
CMake we couldn't find a way to achieve that without changing the CMake
makefiles each time we wanted to combine them in a different way and
this is unacceptable for us.
If you can show a way how arbitrary CMake makefiles can be combined into
different "products" easily, please show an example.
My analysis shouldn't be seen as a judgement about CMake. It's a balance
of pros and cons and an estimation of the expected relation between
effort and benefits, based on the current situation of OOo with our
current build system. In result it looks that investing in the GBuild
approach looks more promising.
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 "[email protected]".
I use it for the OOo lists and only rarely read other mails sent to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
