Am Tue, 11 May 2010 11:54:24 +0400 schrieb Konstantin Tokarev <[email protected]>:
> 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 :) That is not a migration in steps because it would require to make CMake the "master build system" and integrate our currently build system in it. For a project of the size of OOo (and with its number of feature branches/cws) that would be a huge step severely disrupting development -- likely for month. Just see how easy it is to migrate the SCM in a small project and what a major operation it is for OOo. > As for me, major advantages of CMake are: Compared to what? > * speed of initial configuration step, fast re-configuration because > of caching; Does not really apply, because OOo configuration is pretty much 100% custom tests. You would basically need to reimplement our current custom tests and configuration system in CMake for little added value. > * easy setting up of build parameters through ccmake - much more > convenient than those --long-keys; Configuration has little to do with the build system. Dont mix them up just because CMake does. > * more intelligent tracking of source dependencies - less files > require rebuild if something changes than autotools think; Nobody wants to use autotools. The gbuild prototype has full and correct dependencies for C/C++ and also for other targets like our own src/srs/resource files for which we would need to reimplement dependency generation painfully in CMake. > * possibility of parallel build of several directories; Even our current build system does that (badly). CMake does it a little better. GBuild does it a lot better. > * much faster installation - up-to-date binaries are not updated Again: What are you comparing to? > * it's easy to determine operating system of build host and do custom > actions for each platform (e.g., build bundle for Mac) Thats not hard at all. Also, we are currently using custom processes for stuff like packaging and have a lot of special cases that need to be supported so that a preexisting "bundle builder" would not fit our needs as we would need to either heavily modify it or use custom actions anyway. > Again wrong. You can use add_custom_dependencies for each module and > configure build oreder as fine as you need Please read the analysis posted on the wiki. You seem to have misunderstood the limitations of CMake in that regard. > 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 Thats exactly the way to "a lot of headaches". Please read the extensive analysis posted on the wiki. This was not decided without a lot of deep research. As you are still complaining about autotools I have to fear that you have not really had a good look that the analysis and its conclusions. We are not even planning to use autotools for building. We are planning to use GNU make directly as a build system (just as CMake does -- indirectly -- on all unix systems). The configuration system is a completely different issue. It is out of scope for the build system. IMHO one might consider to get rid of autoconf and use CMake for configuration someday -- if only for cosmetic reasons. But as of now I would not consider it worth our rare resources. But changing the build system itself is worth it. Best Regards, Bjoern Michaelsen --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
