[CMake] CONFIGURE_FILE output not cleaned up

Brandon J. Van Every bvanevery at gmail.com
Fri Aug 25 16:19:13 EDT 2006


Eduard Bloch wrote:
>
> Okay. I made a similar thing... removed the absolute path completely so
> it is now generated in CMAKE_BINARY_DIR and I added ${CMAKE_BINARY_DIR}
> to the INCLUDE_DIRECTORIES of each CMakeLists.txt.
>
> This works sufficiently, all new files can be removed by nuking the
> build directory. However, running "make clean" there still does not
> remove those file by itself, it only removes the executable/library
> targets.
>   

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20060825/05a9cbf5/attachment.html


More information about the CMake mailing list