Eduard Bloch wrote:
Philosophically, you're talking about a difference between configuring things and making things. Things that are configured are generally not supposed to be cleaned, either in CMake or in GNU Autotools. A ./configure script will typically generate config.h, and this is not nuked by "make clean" either. I am aware that the GNU Coding Standards don't allow installation pathnames to be expanded at configuration time, only at make time. The Autotools actively enforce this, and their documentation mandates that people perform path substitutions at make time, i.e. using sed in Makefile.am. So, there are motivations to perform substitutions at make time, and to clean them, if only because the GNU Coding Standards are so prevalent out there. If you want to perform substitutions at make time, you will need to write a *.cmake script containing CONFIGURE_FILE, and wrap that script up in an ADD_CUSTOM_COMMAND. You'll have to pass your pathnames with -D flags on the *.cmake script command line. There is a bit of a learning curve about CMake scripting here. It is all kinda tedious, enough so that I feel less like typing up an example, and more like asking how important this is to you? Would the "it's a configuration" philosophy be plenty appropriate for your needs? One final gotcha to watch out for. If you are supporting both ./configure and CMake builds as a legacy transition, ./configure will just dump its config.h in your source tree. You can solve that problem by putting your own config.h in ${CMAKE_CURRENT_BINARY_DIR} and then doing INCLUDE_DIRECTORIES(BEFORE ${CMAKE_CURRENT_BINARY_DIR}), so that your config.h is picked up first. Cheers, Brandon Van Every |
_______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
