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) > add_subdirectory(${PATH_TO_SUN_MODULES}) > endif() would this enable us to cd into some module(i.e. subdirectory) of either the ooo repository or the sun repository, and then enter a command that will build _just_ the files in that module, with the build results going to the same place as if a complete build were started in the root of the ooo repository? > -Bill regards, michael -- "Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we." -- George W. Bush --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
