[CMake] CONFIGURE_FILE output not cleaned up

[Eduard Bloch]

#include <hallo.h>
* Brad King [Fri, Aug 25 2006, 12:22:38PM]:
> Eduard Bloch wrote:
> > CONFIGURE_FILE is used (see below) to adopt an autoconf-style config
> > file, however the result is not cleaned up when the clean target is run.
> > It is not that bad as long as the generated file is not shipped and so
> > the generation is triggered on users machine, but when something
> > unexpected happens then the build will get xconfig.h with wrong
> > contents.
> [snip]
> > How can I make sure that autogenerated files are removed? I tried
> > setting ADDITIONAL_MAKE_CLEAN_FILES even with complete path, it does not
> > help.
> [snip]
> > CONFIGURE_FILE( ${CMAKE_CURRENT_SOURCE_DIR}/xconfig.h.in ${CMAKE_CURRENT_SOURCE_DIR}/xconfig.h)
> 
> With an out of source build no generated file can ever be shipped with
> the source.  You should configure the file to
> ${CMAKE_CURRENT_BINARY_DIR}/xconfig.h instead.  Then you don't have to
> worry about whether it is cleaned out of the source tree.

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.

And the project repository is
http://svn.debian.org/wsvn/debburn/nonameyet/trunk/ , just FYI.

> > SET_SOURCE_FILES_PROPERTIES(xconfig.h PROPERTIES GENERATED 1)
> 
> This is not necessary.  This property is only for outputs of
> ADD_CUSTOM_COMMAND, and it is now automatically added in that case.
> What documentation did you read that mentioned this?

That was a workaround for another previous scenario and is not needed
anymore.

Long story: CMakeLists.txt with xconfig.h-generating code was in a
different directory with the library source and using EXECUTE_PROCESS to
create the file with a custom generator command rather than
CONFIGURE_FILE. "cmake" seemed to ignore the EXECUTE_PROCESS even when
${CMAKE_CURRENT_SOURCE_DIR}/../include/xconfig.h was explicitely listed
among the soure files for the target, and so compiler failed becase the
file was missing.
I got the idea after reading http://www.cmake.org/Wiki/CMake_FAQ and it
worked, the file was generated before the compilation began.
However, later I moved all the generating code to CMakeLists.txt and
CMakeLists.txt to the include directory for cosmetics reason and
SET_SOURCE_FILES_PROPERTIES was still there though apparently unused
(since running make from the parent directory manages to link the
dependencies together, with our without that setting).

> > SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES ${CMAKE_CURRENT_SOURCE_DIR}/xconfig.h ADDITIONAL_MAKE_CLEAN_FILES ${CMAKE_CURRENT_SOURCE_DIR}/align.h)
> 
> The ADDITIONAL_MAKE_CLEAN_FILES property is a string.  You have to
> append the list yourself and then reference the variable:
> 
> LIST(APPEND tmps  ${CMAKE_CURRENT_SOURCE_DIR}/xconfig.h
> ${CMAKE_CURRENT_SOURCE_DIR}/align.h)
> SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${tmps}")

I figured that it needs something like this, see my second example.

Btw, AFAICS Documentation.html lacks a good explanation of what the
lists actually are. It looks like using ${listvar} converts a list to a
string without separators and "${listvar}" to a string-list with
semicolon separators.

But that's not clearly explained there.

Eduard.

-- 
<XTaran> Sachtma, wie ist das nochmal beim dist-upgrade von Woody nach Sarge,
	was muss der Woody-Kernel schon können, damit's nachher auch mit dem
	Sarge zusammen wieder bootet?
<madduck> auf 80386?
/* 2006-06-27 */