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 @[EMAIL PROTECTED]
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@ @[EMAIL PROTECTED]
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
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
