[CMake] Problem with CONFIGURE_FILE and cmakedefine
Karthik Krishnan
Karthik.Krishnan at kitware.com
Wed Mar 22 11:50:02 EST 2006
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
>
More information about the CMake
mailing list