Jussi Pakkanen wrote: > BTW, what does the GNU Make solution use for platform configuration? > Autoconf? Some in-house tool?
We didn't want to change that - so far it's planned to be the same stuff as today (calling our configure script). >> Of course, TANSTAAFL: I'm sure we will be the first to explore this >> (native Windows builds with CMake) for a project of such a big size and >> diversity. Surely we will find many "interesting" problems. But that >> shouldn't stop us from discussing it now. :-) > > KDE builds with CMake on Linux, OSX, and Windows. That's pretty big. We'll see, from our own experience with anything we touched (be it gcc, dbx, the Sun Solaris Compiler, etc.) we get new and interesting problems. That isn't a deal breaker, but it's worth mentioning. > Yes, sure. If and only if you have target_link_libraries(some_exe > some_library) then the linker invocation for some_exe will have > '-lsome_library'. Whether or not it was built accidentally, CMake will > not link the exe against the library. Cool. > I don't know about CMake's internals enough to tell you how it divides > the work between itself and make. But what I can tell you is that > CMake+make combo does handle the entire dependency chain from > executables to source, headers, generated headers etc. It has a > built-in dependency scanner for #includes. Sounds promising. >> I would appreciate to be able to get my hands on it. :-) Trying is so >> much better than talking. Until now I only found rather trivial examples >> in the web (even more trivial like my examples with 4 libraries). > > Attached is a sample with 3 shared libraries and one executable. To > run on Unix, extract it, cd into it, then: > > mkdir builddir > cd builddir > cmake -DCMAKE_BUILD_TYPE=debug .. > make > > It should build without any changes on Linux, OSX, Visual C, MinGW > etc. I always recommend creating a separate build directory so as not > to clutter your source tree with generated files. Thanks, I will try it out. >> BTW: those CMakeList.txt files are a PITA. We are currently moving away >> from cluttering our source tree with files that are not under control of >> the SCM. Is there a way to avoid the placement of these files into the >> source tree? Can it be put somewhere else? > > CMakeLists.txt will be under SCM. They are the master build > information. The generated Makefiles will not be placed under revision > control. They and everything else that is generated can be put into a > separate build directory (this is in fact the recommended way to use > CMake). Of course, sorry, I wanted to mention the generated makefiles, not the sources. :-) Good to hear that this can be moved into a working directory. >> Again this is the problem I want to avoid: errors caused by missing >> dependencies/prerequisites don't appear before you actually execute the >> build. This leaves too much room for random behavior caused by parallel >> builds. > > I don't see how the parallel build thing can happen. Does the current > system have some kind of a wildcard linking rule? Something like "link > against everything in such_and_such directory"? The parallelization comes from the build.pl. Let's go back to our simple example with the 4 libraries/modules. When build.pl is called to build D, it discovers it has to build B and C before (as the build.lst of D tells so). And as B depends on A, build.pl will start either witch building C (and will fail as C also depends on A but that dependency was forgotten in C's build.lst) or with building A (as B's build.lst tells that A needs to be built before B). In the latter case the missing dependency stays unnoticed because A already has been built when finally C is built. The same would happen in a recursive GNU make approach (where GNU make not only would replace dmake but also build.pl): the makefile for D will detect that it needs B and C. It knows by a rule that getting these prerequisites requires invoking the make files for them. So it will execute a make for C or for B, the latter will itself execute make for A (as the makefile of B contains a rule telling so), the former wouldn't do so as a developer forgot to add this rule. Thus if the make for C is called first, the build will fail. If the make for B is called first, the build will not fail as this automatically will call make for A and so will "accidently" provide the missing prerequisite for C and the missing rule will cause no harm: the makfile for C will see the existing library A and everything is fine. In a process that first checks all dependencies in one step before it builds anything this won't happen. The rule to make A is not specified (and evaluated) in the makefile of B and C but in the makefile of D by including the makefile of A directly. >> BTW: how does CMake organize the parallel build? The "all in one >> process" approach has another major advantage: as it is one process, it >> can find the optimum distribution for the available processes. This is >> not possible if the build runs in several processes, even if they are >> called recursively. > > Again I don't know about the implementation. But when I run 'make -j > 17' on a 16 core machine and then run top, I get 100% CPU utilization > almost all of the time. So it definitely "works for me". Whether it > does for you is a matter of testing. How good the build scales depends on the stuff to build. But OK, I think we will figure that out. Thanks for your answers, now it's time to try your example and then talk with Martin about his findings with our source code. I will report back. 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...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
