On 10/06/2010 20:19, Bill Hoffman wrote:
On 6/1/2010 8:30 AM, Mathias Bauer wrote:
Hi Bill,
it took longer than expected, but here we are. I took the CMake build
protoype again, that my colleague Martin Hollmichel provided, and gave
it another whirl. The results didn't change much.
It seems to have taken me just as long... Where is the prototype CMake
build, perhaps I should take a look at it. :)
i think it is in the cws mh6bc (yay for intuitive naming!), which is
available via hg here:
http://hg.services.openoffice.org/hg/cws/mh6bc/
[snip]
Another aspect of CMake that you do not address in your evaluation is
that fact that with CMake you will be outsourcing the maintenance of
the build system to the CMake developers.
Sure, that goes without a saying. But we also don't plan to take over
the maintenance of GNU Make ;-).
So, the thing that CMake brings to the table is the platform support.
CMake knows how to build .so, .dll, .exe on all sorts of platforms. See
the cmake dashboard for a list:
http://www.cdash.org/CDash/index.php?project=CMake
We spend lots of time making sure all of that works on many different
systems.
hmm, ok.
well, for the most part building libraries and executables is what is now
implemented in the gbuild system / gnumake2 cws.
but your point about the maintenance is taken.
[snip]
To my knowledge based on lurking on the mailing list and reading the
documentation on your web site I concluded that CMake can be used
recursively only. I would be glad if you could prove me wrong and show
us that we can use CMake in a non-recursive way too without losing
something else and that we won't run into scalability problems with our
huge project. An example for what that could be: we made some
scalability tests for GNU Make before we started using it and discovered
that it doesn't scale well with the number of rules above ~25000 rules
or so, but that could be fixed easily by using pattern rules as much as
possible.
We did attempt to create non-recursive makefiles for CMake, and they are
less recursive than they once were. However, we found it impossible
to handle implicit dependencies of generated source files without using
recursive calls to make. If you have a solution for that, we would be
very receptive.
i believe the gbuild system is designed so that GNU make will restart
itself automatically in such circumstances.
but i don't know how that works, maybe Björn will explain it...
Another topic that is mentioned is the fact that builds have to be run
from the top. That is not entirely true. You can have subprojects that
are built on their own. Each add_subdirectory can point to a complete
project. If you cd into the sub directory in the build tree, you can
just run make, and it will only build the targets associated with that
sub-project. Also, you could run cmake on the sub-project by itself if
it is written to work as an independent sub-project.
I never wanted to say that with CMake you always have to run from the
top. But it seemed to me that by organizing the build in a way to allow
more flexibility I lose other things.
Sure, we can create a CMake makefile for each module we want to be able
to build invidually and make it an own CMake project. But of course we
still want to have the full build over all modules, and we need its
result in the same working directory as the build of the individual
modules.
The project structure we are aiming at would look this way:
-ooo
--mod1
--mod2
...
--modn
-sun
--sun-mod1
--sun-mod2
...
--sun-modn
We have these two top level projects because we want to build OOo and
our commercial variant from the same source tree, as they share most of
the code.
We want to go to any sub module and build it independently from the
rest, if possible without any external dependencies to other modules. Of
course this would require that all other modules below had been built
before at some time. If you ask why building single modules inside the
whole tree is so important: remember the long time it takes on Windows
to traverse through modules where nothing has to be built.
We want to go into any of the two top modules (here named ooo and sun)
and do a complete build, with all dependencies evaluated correctly as we
would get it for a normal project without sub projects.
We want to share the working directory between the two top level
projects as we don't want to build the common parts twice, but each of
them must be buildable separately as outside of our Hamburg lab only one
top level project exists.
How do I have to setup a CMake build to support that build structure?
I am not totally sure I understand what you are wanted here...
One that that comes to mind is the concept of out of source source...
Basically give add_subdirectory a directory that is not in the same
source tree.
Something like this:
if(BUILD_WITH_SUN)
