[CMake] CONFIGURE_FILE output not cleaned up

[Brandon J. Van Every]

Eduard Bloch wrote:
> #include <hallo.h>
> * Brandon J. Van Every [Fri, Aug 25 2006, 01:19:13PM]:
>   
>> 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.
>>     
>
> In theory, yes. However, the need to configure something and put the
> result down in a include file is IMO a common case among portable
> programs. I know that this action is an additional level of operation
> placed beetween cmake configuration and the final making. So effectively
> there should be a way to _simply_ define a temporary product (the
> config.h file) as target which other targets do pre-depend on (so the
> first must be proccessed before making others and never be executed
> simultaneosly). And I wish there would be "virtual prerequisites", eg.
> the operation would be triggered if the hostname or kernel version
> changes. And there should be a "distclean" rule to remove such temporary
> products like configuration headers. Alternatively, the config files may
> be kept but then the detection of their pre-requisites must be
> waterproof.
>   

Good fodder for a feature request.  Use the bug tracker to make it.  
http://www.cmake.org/Bug/  I agree that I'd like to not have to do a 
song and dance to get a configuration file to be cleaned.  At present, I 
simply re-run CMakeSetup, and that's adequate to my needs.  I always do 
out-of-directory builds, so if I want everything to be "distclean," I 
just wipe my build tree and start from scratch.  Again this is adequate 
to my needs.

>   
>> 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?
>>     
>
> I am not sure whether it is okay for may needs. Because I am not sure
> that I understand the design goals of cmake to 100 percent. I would like
> to see in clear sentenses what exactly is triggering what when cmake
> does things.
>
> What you describe may be something like I mentioned above scripted in
> the cmake language, but I don't know how and when the code will be
> executed and how I can influence this to be executed not too often but
> also always then when it is needed.
>
>   

An ADD_CUSTOM_COMMAND is just a dependency rule.  It has the same 
functionality as a rule in a makefile, gets invoked at the same time as 
such rules, and indeed is just syntax for specifying such rules in a 
cross-platform way.

CMake scripting is just what you're choosing to do.  You could choose to 
use native platform tools, like sed or awk or perl or whatever.  CMake 
doesn't care.  That's why it's a *CUSTOM* command.


Cheers,
Brandon Van Every

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20060828/59b7f69f/attachment.htm