[CMake] Problem with CONFIGURE_FILE and cmakedefine

[David Cole]

This works for me, producing (I suspect) your expected results:

foo.h:
/* #undef vtk_OPTION */

It worked for me with both CMake 2.2.3 and a CVS CMake: "cmake version 
2.3-20060301"... (Windows XP)

It was probably broken at the time you took your CMake build snapshot. I 
would recommend sticking with a released CMake or live CVS CMake... (Or 
at least a more recent snapshot.)


HTH,
David


Karthik Krishnan wrote:

> Karthik Krishnan wrote:
>
>> Hello,
>>
>> CMakeLists.txt:
>>  SET( NAMESPACE "vtk" )
>>  SET( ${NAMESPACE}_OPTION "ON" )
>>  CONFIGURE_FILE( ${CMAKE_CURRENT_SOURCE_DIR}/foo.h.in 
>> ${CMAKE_CURRENT_BINARY_DIR}/foo.h @ONLY IMMEDIATE )
>>
>> foo.h.in
>>   #cmakedefine @NAMESPACE at _OPTION
>>
>>
>> This does not place the #define vtk_OPTION in foo.h. Replacing the 
>> @NAMESPACE@ in foo.h.in with vtk works though.
>> It looks like the CONFIGURE_FILE is being parsed after the 
>> #cmakedefine checks.
>>
>> Is this intended behaviour ?
>
>
> Never mind, answering myself, can be done with a double configure.
>
> CMakeLists.txt:
>  SET( NAMESPACE "vtk" )
>  SET( ${NAMESPACE}_OPTION "ON" )
>  SET( CMAKEDEFINE "#cmakedefine" )
>  CONFIGURE_FILE( ${CMAKE_CURRENT_SOURCE_DIR}/foo.h.in 
> ${CMAKE_CURRENT_BINARY_DIR}/tmp.h.in @ONLY IMMEDIATE)
>  CONFIGURE_FILE( ${CMAKE_CURRENT_BINARY_DIR}/tmp.h.in 
> ${CMAKE_CURRENT_BINARY_DIR}/foo.h @ONLY IMMEDIATE)
>
> foo.h.in
>  @CMAKEDEFINE@ @NAMESPACE at _OPTION
>
> Still wondering if that was the intended behaviour. (cmake version 
> 2.3-20060128)
>
> Thanks
> -karthik
>
>>
>> thanks
>> -karthik
>>
>> Alexander Neundorf wrote:
>>
>>> Hi,
>>> recently cmake cvs has the new FILE() command:
>>> FILE(SYSTEM_PATH ENVIRONMENT_VARIABLE _variable)
>>> Now, there's the case that some tool outputs a list of directories 
>>> (e.g. kde-config), which will also contain the backward slashes. For 
>>> use with cmake the backslashes have to be replaced forward slashes. 
>>> Basically this is what is done with FILE(SYSTEM_PATH ...) But this 
>>> doesn't work for output from applications.
>>> We have currently the following code in FindKDE4.cmake:
>>> # then ask kde-config for the kde data dirs 
>>> EXEC_PROGRAM(${KDE4_KDECONFIG_EXECUTABLE} ARGS --path data 
>>> OUTPUT_VARIABLE _data_DIR )
>>> IF(WIN32)   # cmake can't handle paths with '\' correct :-(   
>>> STRING(REGEX REPLACE "\\\\" "/" _data_DIR "${_data_DIR}") 
>>> ELSE(WIN32)   # replace the ":" with ";" so that it becomes a valid 
>>> cmake list   STRING(REGEX REPLACE ":" ";" _data_DIR "${_data_DIR}") 
>>> ENDIF(WIN32)
>>>
>>> Maybe it would be a better idea to remove FILE(SYSTEM_PATH ...) 
>>> again and instead add something like this:
>>> set(myPath $ENV{KDEDIRS}) TO_CMAKE(myKdeDirs ${myPath})  ?
>>> This would work for both cases, the env. var and if the content 
>>> comes from somewhere else. What do you think ?
>>> Bye Alex
>>>
>>>
>>>  
>>>
>> _______________________________________________
>> CMake mailing list
>> CMake at cmake.org
>> http://www.cmake.org/mailman/listinfo/cmake
>>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>