[CMake] Problem with CONFIGURE_FILE and cmakedefine

[Karthik Krishnan]

David Cole wrote:

> This works for me, producing (I suspect) your expected results:
>
> foo.h:
> /* #undef vtk_OPTION */
>
The expected result (for 
http://public.kitware.com/pipermail/cmake/2006-March/008684.html)

#define vtk_OPTION

which it did not produce. (Neither does CMake 2.2.3) ?

thanks
-karthik

> 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
>>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>