[CMake] Problem with CONFIGURE_FILE and cmakedefine

[David Cole]

Given that the "argument" to cmakedefine is supposed to be a CMake 
variable name, I'm guessing that your double configure is the right way 
to do what you want. And that the behavior your observing is the 
intended behavior...

Karthik Krishnan wrote:

> 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
>>
>