Hi,
I noticed the discussion about CMake, and wanted a chance to answer some
of the questions raised about CMake. Sorry for starting a new thread,
but I just joined the list. If you want to move this back to the old
thread, please just answer my comments on that thread, I will look for it.
Sure, but CMake does not have target local variables, dynamic evaluation
etc. that make that usable in a large scale project.
I am not sure what the question is here. CMake does have various forms
of local variables.
- All variables in the cmake function command are local to that
function, and can be optionally moved up to a parent scope.
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:function
- CMake also has target properties that can be set. These are
properties that are attached to a target.
See the documentation for set_target_properties here:
cmake.org/cmake/help/cmake-2-8-docs.html#command:set_target_properties
- CMake is certainly being used for many large projects, so I am not
sure what dynamic eval you are asking about.
The biggest problem of a switch to CMake besides the ones already
mentioned is that it does not offer a migration path for us.
Switching our build system to CMake would require a one shot
conversion, including parallel maintenance of makefiles for the whole
duration of the switch (that is estimated to last for several
months).
There are ways to do this. In particular, a recent addition to CMake
call external projects might be useful.
For example, you can "build" Qt from a cmake file like this:
ExternalProject_Add(Qt
DOWNLOAD_DIR ${CMAKE_CURRENT_BINARY_DIR}
URL ${qt_file}
UPDATE_COMMAND ""
SOURCE_DIR ${qt_source}
BUILD_IN_SOURCE 1
CONFIGURE_COMMAND ${qt_configure}
BUILD_COMMAND ${qt_build}
INSTALL_COMMAND "${qt_install}"
)
This could be used to drive the existing build system of open office.
So, you could have a tree of CMake built sub-parts of openoffice, and a
tree that still uses the current build system. An umbrella CMake build
file could be constructed to build external projects for each part of
the system. I am pretty sure that you could get there incrementally if
you wanted to.
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.
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. CMake will be creating shared
libraries, mac OSX bundles, install rules, rpath manipulation,
potentially packaging in the future, and lots of other features. CMake
is not a static project, and has lots of development going on. Your
project could enjoy some of that effort, and perhaps guide it if you
joined the CMake community. For more general information about the
whole CMake tool set, you might be interested in the google tech talk
that I did:
http://www.kitware.com/blog/home/post/2
-Bill
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
[email protected]
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
