Re: [CMake] Swig dependencies not being tested?
Quoting Alan W. Irwin [EMAIL PROTECTED]:
On 2007-12-10 05:33+0100 Christiaan Putter wrote:
I know swig support isn't all that great at the moment but was wondering if
someone happens to have a working Swig module for cmake that doesn't rebuild
every time even without the dependencies having changed.
I do confirm that is a problem, and I hope somebody fixes it.
The problem only exists for FindPythonLibs.cmake, though, as the
rebuilding does not happen for Perl (once FindPerlLibs.cmake is fixed,
see bug db) or Ruby.
Someone else also pointed out a problem with .i files having to be in the
current source dir.
We have never felt constrained by that limitation (in fact I was unaware of
it) since it is possible to specify just one *.i file in the current source
directory that then includes *.i files from elsewhere in the source tree.
I could also copy the .i file multiple times but that somewhat defeats
the purpose. I have a bug open for that.
Same goes for target naming: the output name and the cmake target name
have a too close relationsship (the former is derived from the
latter). And since the binding language is not taken into account for
the cmake target name, one practically must do that himself and then
use SET_TARGET_PROPERTIES to change the OUTPUT_NAME to something
useful. Very inconvenient.
Cmake target name should be: ${SWIG_TARGET_NAME)_${SWIG_LANGUAGE}
and output name then only derived from ${SWIG_TARGET_NAME}
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Building debug targets
Hi all, I want to built debug target with cmake and nmake . I am calling cmake with -DCMAKE_BUILD_TYPE=Debug.later i am calling nmake. But everytime nmake is building release target. Is there any other way to build debug target??? Thanks in advance Ramazan ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
- The source code seems to have been crappified by windows. There's missing +x permissions on executable files and cr-lf linefeeds everywhere. - The source does: #include lua.h but the bootstrap/cmakelists.xt does not search for paths to it. Under my Ubuntu box, lua.h is located in lua5.1/lua.h or lua5.0/lua.h, not under the main /usr/include. So I'm wondering if there is a cleaned up version of the code yet. I'm having a hard time dealing with both the cr-lf and the Lua detection on my Mac. - The approach of a single cmCommand.cxx to parse functions is probably limiting as it makes it harder to make the command syntax more flexible. I wanted to comment on this. I think this is a workable situation. I was thinking, instead of trying to change things at the C++ level, it would be a lot easier to handle this at the Lua level. We can create a CMake/LuaUtility module which always gets included and create a public API there. Each public API function in here basically just calls the CMake/Lua function that was binded in cmCommand.cxx. But in the utility module, we do all the argument parsing and validation we see fit. I've submitted an example and updated the page: http://www.cmake.org/Wiki/CMake:Experiments_With_Lua The example shows different ways scripters may want to pass files to add_library and a simple function that handles it. Thanks, Eric ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 4
Hi, sorry for the delay, but I just sacrificed my weekend trying to get caught up on CMake things. So all the issues are fuzzy. But here's what I remember: - The bootstrap used to fail if CMake had not been previously installed. I just tested this on a system that did not have CMake installed and the thing seemed to bootstrap and build okay. - This brought up issues about the Mac OS X Deployment Target and also the Min Version. This also brought up issues about keeping the fields separate (which I think we have to do), and how to pick default values. I also have a secondary issue of how do I deal with code that is OS X version dependent? I have two different files, one based on new stuff that only exists in Tiger+, and the other that uses legacy stuff that is marked deprecated in Tiger. For 10.4+, I want to build the former file. For 10.3-, I want to build the latter. This reminds me of several different issues we have discussed in CMake. 1) We don't have a clean way of detecting the OS X version number we are on, only the Darwin number. 2) The SDK detection code is fragile because it looks for certain directory names in certain locations. 3) Speaking of locations, Xcode is now relocatable in Leopard. 4) Speaking of Xcode Leopard, there is a real push by Apple to require SDK selection for everything, and now an optional install that doesn't install all the standard Unix development tools. We also have the Framework building support issues. Last time, we spoke of this, we were having problems with versioning schemes. There is .so, .dylib, framework, where .so conflicted with .dylib. I just checked, and it does not appear to be fixed. We also ended up talking about install_name, rpath, and now @rpath. There were also other minor things with frameworks such as symlinks being creating to nothing and unnecessary directories being created. Another issue not explicitly discussed by me, but has been mentioned in other contexts is installing to /usr instead of /usr/local. I haven't checked in awhile, but last time I remember, the installer package for CMake installs to /usr instead of /usr/local. This really needs to change if it hasn't already been fixed. That's all I can remember on Mac issues for the moment. But on a general CMake issue, I just submitted a whole bunch of Find*.cmake modules for inclusion. http://www.cmake.org/Bug/view.php?id=6139 Some of them are updates to existing modules that I have contributed. Others are brand new modules that I've been promising but needed to do significant clean up before submitting. (So that's where my weekend went.) FindFreeType.cmake FindGDAL.cmake FindGIFLIB.cmake FindLua50.cmake FindLua51.cmake FindOpenAL.cmake FindOpenSceneGraph.cmake FindOpenThreads.cmake FindPhysFS.cmake FindProducer.cmake FindQuickTime.cmake FindSDL.cmake FindSDL_image.cmake FindSDL_mixer.cmake FindSDL_net.cmake FindSDL_sound.cmake FindSDL_ttf.cmake Findosg.cmake FindosgDB.cmake FindosgFX.cmake FindosgGA.cmake FindosgIntrospection.cmake FindosgManipulator.cmake FindosgParticle.cmake FindosgProducer.cmake FindosgShadow.cmake FindosgSim.cmake FindosgTerrain.cmake FindosgText.cmake FindosgUtil.cmake FindosgViewer.cmake Thanks, Eric On 12/6/07, Sean McBride [EMAIL PROTECTED] wrote: On 12/6/07 2:31 PM, Bill Hoffman said: What would we have to do to get the OS X 10.5 fixes in the 2.4.8 branch? More and more users are switching to Leopard and having a working cmake under 10.5 is extremely important, not to mention good PR when you release CMake as Leopard Ready. I don't remember the list of things that were done, do you have a list? I'm afraid not. :( IIRC, most of the issues we worked out in an email discussion between Bill, Eric, and myself. We were not diligent about filing bugs for each issue. Eric, do you remember any details? Anyone have time to see if 2.4.8 can bootstrap itself? 2.5 was not able to a few weeks ago, but can now. BTW Bill, thanks for agreeing to move the 4605 fix into 2.4.8. -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 4
E. Wing wrote: Hi, sorry for the delay, but I just sacrificed my weekend trying to get caught up on CMake things. Thanks! So all the issues are fuzzy. But here's what I remember: We also have the Framework building support issues. Last time, we spoke of this, we were having problems with versioning schemes. There is .so, .dylib, framework, where .so conflicted with .dylib. I just checked, and it does not appear to be fixed. We also ended up talking about install_name, rpath, and now @rpath. There were also other minor things with frameworks such as symlinks being creating to nothing and unnecessary directories being created. Another issue not explicitly discussed by me, but has been mentioned in other contexts is installing to /usr instead of /usr/local. I haven't checked in awhile, but last time I remember, the installer package for CMake installs to /usr instead of /usr/local. This really needs to change if it hasn't already been fixed. Eric, if you could try 2.4.8 RC 4 and see what is missing that would help a lot. I am not planning to fix or develop much more for 2.4.8. Any new stuff or major changes will go in 2.6. So, 2.4.8 will not have the ability to create frameworks. 2.4.8 is for fixing regressions and bugs of 2.4.7 and not filling in missing features or working out long standing issues. The problem with adding new stuff is that for each new thing we add, it is sure to bring 2 more bugs... :) So, please just bug fixes for 2.4.8. The general rules are: - Does something not work in 2.4.8 that worked in 2.4.7 - Is there something that worked in 2.4.6- 2.4.0 that is broken in 2.4.7 - Is there something that is just a simple bug in 2.4.7, and advertised feature that does not work. Most everything else belongs in 2.6.0. That's all I can remember on Mac issues for the moment. But on a general CMake issue, I just submitted a whole bunch of Find*.cmake modules for inclusion. http://www.cmake.org/Bug/view.php?id=6139 Eric, the bug tracker is a real pain to handle module contributions. This is why I setup the module maintainers. Would you like to become a module maintainer? http://www.cmake.org/Wiki/CMake:Module_Maintainers You would get CVS access to the Modules directory in CMake, and you would not have to wait for me to get around to extracting your modules from the bug tracker. Thanks -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Specifying different flags for debug/release mode
Hi, ist there something like target_link_libraries(debug fooD.lib release foo.lib) possible for flags? It's needed to make Qt plugins work (yes, you can't properly build Qt plugins on windows with cmake). Christian -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Specifying different flags for debug/release mode
Quoting Christian Ehrlicher [EMAIL PROTECTED]: Hi, ist there something like target_link_libraries(debug fooD.lib release foo.lib) possible for flags? It's needed to make Qt plugins work (yes, you can't properly build Qt plugins on windows with cmake). From http://www.cmake.org/Wiki/CMake_Useful_Variables CMAKE_BUILD_TYPE Choose the type of build. CMake has default flags for these: None (CMAKE_C_FLAGS or CMAKE_CXX_FLAGS used) Debug (CMAKE_C_FLAGS_DEBUG or CMAKE_CXX_FLAGS_DEBUG) Release (CMAKE_C_FLAGS_RELEASE or CMAKE_CXX_FLAGS_RELEASE) RelWithDebInfo (CMAKE_C_FLAGS_RELWITHDEBINFO or CMAKE_CXX_FLAGS_RELWITHDEBINFO MinSizeRel (CMAKE_C_FLAGS_MINSIZEREL or CMAKE_CXX_FLAGS_MINSIZEREL) Example: SET(CMAKE_BUILD_TYPE Debug) You can create your own build type like this: SET(CMAKE_BUILD_TYPE distribution) SET(CMAKE_CXX_FLAGS_DISTRIBUTION -O3) SET(CMAKE_C_FLAGS_DISTRIBUTION -O3) Note that CMAKE_BUILD_TYPE is not initialized with a readable value at configuration time. This is because the user is free to select a build type at build time. Use CMAKE_CFG_INTDIR if you need a variable that evaluates to the correct build time directory. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Mangled library names
What's the best way to produce mangled library names (encoding in the target name some configuration properties)? Examples of mangled library names are here, in Boost: http://www.boost.org/more/getting_started/windows.html#library-naming TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Specifying different flags for debug/release mode
Von: Pau Garcia i Quiles Quoting Christian Ehrlicher Hi, ist there something like target_link_libraries(debug fooD.lib release foo.lib) possible for flags? It's needed to make Qt plugins work (yes, you can't properly build Qt plugins on windows with cmake). From http://www.cmake.org/Wiki/CMake_Useful_Variables CMAKE_BUILD_TYPE Choose the type of build. CMake has default flags for these: None (CMAKE_C_FLAGS or CMAKE_CXX_FLAGS used) Debug (CMAKE_C_FLAGS_DEBUG or CMAKE_CXX_FLAGS_DEBUG) Release (CMAKE_C_FLAGS_RELEASE or CMAKE_CXX_FLAGS_RELEASE) RelWithDebInfo (CMAKE_C_FLAGS_RELWITHDEBINFO or CMAKE_CXX_FLAGS_RELWITHDEBINFO This does not help much/ I'm currently using this hack. The problem is that it's not permanent. And the other one is that imho FindQt4.cmake should handle this. See http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/FindKDE4Internal.cmake?r1=733507r2=734116 http://www.cmake.org/pipermail/cmake/2007-November/017541.html Therefore I'm looking for an easier solution to solve this. Christian -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Specifying different flags for debug/release mode
Christian Ehrlicher wrote: Hi, ist there something like target_link_libraries(debug fooD.lib release foo.lib) possible for flags? It's needed to make Qt plugins work (yes, you can't properly build Qt plugins on windows with cmake). Christian This was fixed recently in CVS for Qt projects. If you want to grab it, build it and give it a try, go ahead. Or you can stick with whatever CMake version you're using and copy what it does in UseQt4.cmake to define QT_NO_DEBUG into your project's CMakeLists.txt file. http://www.cmake.org/cgi-bin/viewcvs.cgi/Modules/UseQt4.cmake?root=CMakeview=markup Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Swig dependencies not being tested?
On Dec 10, 2007 7:15 AM, Alan W. Irwin [EMAIL PROTECTED] wrote:
On 2007-12-10 05:33+0100 Christiaan Putter wrote:
Hi all,
I know swig support isn't all that great at the moment but was wondering if
someone happens to have a working Swig module for cmake that doesn't rebuild
every time even without the dependencies having changed.
I do confirm that is a problem, and I hope somebody fixes it.
I use the Swig module, the one provided by CMake, and it's working
well. Swig wrappers generation and library compilation are properly
managed (not rebuild all the time). I use it the same way than Alan
described: only one swig file, which takes care of all inclusions, is
provided to the macro SWIG_ADD_MODULE. To specify missing
dependencies, I use the variable `SWIG_MODULE_module_EXTRA_DEPS':
SET(SWIG_MODULE_foo_EXTRA_DEPS bar.i foobar.i bar.h ...)
SWIG_ADD_MODULE(foo PYTHON foo.i)
Attached to #4147, you can find a macro
`SWIG_GET_WRAPPER_DEPENDENCIES' which use -MM option provided by Swig
to compute dependencies. This intend to replace use of variable
SWIG_MODULE_module_EXTRA_DEPS
Could you please describe a use case which create the unnecessary
rebuilt of your project?
Someone else also pointed out a problem with .i files having to be in the
current source dir.
We have never felt constrained by that limitation (in fact I was unaware of
it) since it is possible to specify just one *.i file in the current source
directory that then includes *.i files from elsewhere in the source tree.
+1
Despite the convenience of this approach, others will have different needs
that would best be served by allowing the initial *.i file (that includes
the rest of the *.i files) to be somewhere else than the current source
directory so on these general grounds I hope this limitation is removed
at the same time as when the dependency problem is fixed.
I agree, it should work.
I guess it is alright if you specify a path like ../common.i but not
something like ${CMAKE_SOURCE_DIR}/swig/common.i.
--
Tristan Carel
Music with dinner is an insult both to the cook and the violinist.
http://www.tristancarel.com
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Multiple configurations in a single target?
Hi A single VS .vcproj file can have both debug and release configurations. How can I produce that sort of project file with CMake? Would calling CMake twice, setting CMAKE_BUILD_TYPE differently each time, do the magic? TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple configurations in a single target?
Hi A single VS .vcproj file can have both debug and release configurations. How can I produce that sort of project file with CMake? Would calling CMake twice, setting CMAKE_BUILD_TYPE differently each time, do the magic? Hi, I don't understand your question, by default CMake generates .vcproj files with the following configurations: Debug;Release;MinSizeRel;RelWithDebInfo So you don't have to do anything to get them into your Visual Studio project. --Sylvain ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Multiple configurations in a single target?
Sylvain Benner wrote: Hi A single VS .vcproj file can have both debug and release configurations. How can I produce that sort of project file with CMake? Would calling CMake twice, setting CMAKE_BUILD_TYPE differently each time, do the magic? Hi, I don't understand your question, by default CMake generates .vcproj files with the following configurations: Debug;Release;MinSizeRel;RelWithDebInfo So you don't have to do anything to get them into your Visual Studio project. Ha OK, I missed that because I read here that CMAKE_BUILD_TYPE had to be set by the user, so I just assumed it would produce only one configuration depending on that. Well, the real question now then: to have each configuration has its own properties, like target name, definitions and dependecies, I just need to switch on CMAKE_BUILD_TYPE? TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Swig dependencies not being tested?
On 2007-12-10 10:12+0100 Hendrik Sattler wrote: Quoting Alan W. Irwin [EMAIL PROTECTED]: Someone else also pointed out a problem with .i files having to be in the current source dir. We have never felt constrained by that limitation (in fact I was unaware of it) since it is possible to specify just one *.i file in the current source directory that then includes *.i files from elsewhere in the source tree. I could also copy the .i file multiple times but that somewhat defeats the purpose. I have a bug open for that. Just to clarify we do not copy *.i files or have duplicate *.i information in multiple files for our particular swig configuration. Instead, we keep all the common swig information (e.g., the definition of our library's API) in one large common file which is included by our relatively small language-specific swig *.i files. If you are unable/unwilling to use a similar organization (small language-specific *.i files which include *.i files with the common swig information) and therefore are forced by the above CMake limitation to copy *.i files for your particular swig needs, then obviously the removal of that CMake limitation is a high priority for you. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Swig dependencies not being tested?
I have a modified version of the Swig module (edited before the
EXTRA_DEPS flag was present). It uses the -MM to create dependencies
and a python script to convert the file into a CMake consumable
version. The make2cmake.py file could be rewritten in cmake script (see
below). It just needs some regular expression magic. We've done it for
other compilers (cuda), but I haven't bothered since I had one that just
worked.
You can find the code in our online repository.
svn cat
https://code.sci.utah.edu/svn/Manta/trunk/CMake/MantaUseSWIG.cmake
MantaUseSWIG.cmake
svn cat https://code.sci.utah.edu/svn/Manta/trunk/CMake/make2cmake.py
make2cmake.py
svn cat https://code.sci.utah.edu/svn/Manta/trunk/CMake/empty.depend.in
empty.depend.in
You don't have to do anything special on the using side. It can be used
as a drop in replacement for the existing swig module. You just have to
place these three files in a CMake directory at the top of your source tree.
The mechanics were takes from some code I found in VTK. You create two
additional targets. One generates the .swig-depends file via swig -MM.
The next converts the file to a cmake readable form. Swig doesn't
regenerate the .swig-depends file if the dependencies don't change, so
you get reasonable behavior. We've been using this script for a couple
of years now with out problems.
James
P.S. Here's my first stab at a make2cmake.cmake script (note it probably
isn't complete).
SET(IN_FILENAME test.swig-depend)
MESSAGE(IN_FILENAME = ${IN_FILENAME})
FILE(READ ${IN_FILENAME} FILESTUFF)
MESSAGE(FILESTUFF = ${FILESTUFF})
STRING(REGEX REPLACE ^.*:[ ]*\n FILESTUFF ${FILESTUFF})
STRING(REGEX REPLACE [ ]*\n ; FILESTUFF ${FILESTUFF})
MESSAGE(FIXED = ${FILESTUFF})
FOREACH(VAR ${FILESTUFF})
MESSAGE(VAR = ${VAR})
ENDFOREACH(VAR)
We did get this working for cuda, but the regular expression may need to
be modified to the one above.
svn cat
https://code.sci.utah.edu/svn/people/abe/code/CMake-cuda/CMake/cuda/make2cmake.cmake
make2cmake.cmake
On Dec 10, 2007, at 9:08 AM, Tristan Carel wrote:
On Dec 10, 2007 7:15 AM, Alan W. Irwin [EMAIL PROTECTED] wrote:
On 2007-12-10 05:33+0100 Christiaan Putter wrote:
Hi all,
I know swig support isn't all that great at the moment but was
wondering if
someone happens to have a working Swig module for cmake that doesn't
rebuild
every time even without the dependencies having changed.
I do confirm that is a problem, and I hope somebody fixes it.
I use the Swig module, the one provided by CMake, and it's working
well. Swig wrappers generation and library compilation are properly
managed (not rebuild all the time). I use it the same way than Alan
described: only one swig file, which takes care of all inclusions, is
provided to the macro SWIG_ADD_MODULE. To specify missing
dependencies, I use the variable `SWIG_MODULE_module_EXTRA_DEPS':
SET(SWIG_MODULE_foo_EXTRA_DEPS bar.i foobar.i bar.h ...)
SWIG_ADD_MODULE(foo PYTHON foo.i)
Attached to #4147, you can find a macro
`SWIG_GET_WRAPPER_DEPENDENCIES' which use -MM option provided by Swig
to compute dependencies. This intend to replace use of variable
SWIG_MODULE_module_EXTRA_DEPS
Could you please describe a use case which create the unnecessary
rebuilt of your project?
Someone else also pointed out a problem with .i files having to be
in the
current source dir.
We have never felt constrained by that limitation (in fact I was
unaware of
it) since it is possible to specify just one *.i file in the current
source
directory that then includes *.i files from elsewhere in the source tree.
+1
Despite the convenience of this approach, others will have different
needs
that would best be served by allowing the initial *.i file (that includes
the rest of the *.i files) to be somewhere else than the current source
directory so on these general grounds I hope this limitation is removed
at the same time as when the dependency problem is fixed.
I agree, it should work.
I guess it is alright if you specify a path like ../common.i but not
something like ${CMAKE_SOURCE_DIR}/swig/common.i.
--
Tristan Carel
Music with dinner is an insult both to the cook and the violinist.
http://www.tristancarel.com
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Swig dependencies not being tested?
On 2007-12-10 17:08+0100 Tristan Carel wrote:
On Dec 10, 2007 7:15 AM, Alan W. Irwin [EMAIL PROTECTED] wrote:
On 2007-12-10 05:33+0100 Christiaan Putter wrote:
Hi all,
I know swig support isn't all that great at the moment but was wondering if
someone happens to have a working Swig module for cmake that doesn't rebuild
every time even without the dependencies having changed.
I do confirm that is a problem, and I hope somebody fixes it.
I use the Swig module, the one provided by CMake, and it's working
well. Swig wrappers generation and library compilation are properly
managed (not rebuild all the time). I use it the same way than Alan
described: only one swig file, which takes care of all inclusions, is
provided to the macro SWIG_ADD_MODULE. To specify missing
dependencies, I use the variable `SWIG_MODULE_module_EXTRA_DEPS':
One weakness of the previous PLplot implementation was the lack of
dependency on the common file, but now I am using
SWIG_MODULE_module_EXTRA_DEPS to provide that. Thanks for drawing my
attention to that possibility.
However, that is a side issue from the problem that swig is always re-invoked
(for the PLplot case) which means the interface always gets rebuilt. Here
are some more details.
CMakeLists.txt fragment:
# This is currently the include list for swig, the C wrapper and the
# the Python headers. Not particular pretty...
set(python_interface_INCLUDE_PATHS
${CMAKE_SOURCE_DIR}/include
${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}/include
${CMAKE_CURRENT_BINARY_DIR}
${PYTHON_INCLUDE_PATH}
${CMAKE_SOURCE_DIR}/bindings/swig-support
)
include_directories(${python_interface_INCLUDE_PATHS})
set(CMAKE_SWIG_FLAGS -DPL_DOUBLE -DSWIG_PYTHON -python)
set(CMAKE_SWIG_OUTDIR ${CMAKE_CURRENT_BINARY_DIR})
set(SWIG_MODULE_plplotcmodule_EXTRA_DEPS
${CMAKE_SOURCE_DIR}/bindings/swig-support/plplotcapi.i)
# Set up swig + c wrapper.
# N.B. the python target has an underscore prepended automatically.
swig_add_module(plplotcmodule python plplotcmodule.i)
swig_link_libraries(plplotcmodule plplot${LIB_TAG} ${PYTHON_LIBRARIES})
If I rerun make, here is the (partial) verbose result showing that swig is
re-run, then the interface is rebuilt:
make -f bindings/python/CMakeFiles/_plplotcmodule.dir/build.make
bindings/python/CMakeFiles/_plplotcmodule.dir/depend
make[2]: Entering directory `/home/software/plplot_cvs/HEAD/build_dir'
/usr/bin/cmake -E cmake_progress_report /home/software/plplot_cvs/HEAD/build_dir/CMakeFiles
[ 9%] Swig source
cd /home/software/plplot_cvs/HEAD/build_dir/bindings/python /usr/bin/swig
-python -DPL_DOUBLE -DSWIG_PYTHON -python -outdir
/home/software/plplot_cvs/HEAD/build_dir/bindings/python
-I/home/software/plplot_cvs/HEAD/plplot_cmake/include
-I/home/software/plplot_cvs/HEAD/build_dir
-I/home/software/plplot_cvs/HEAD/build_dir/include
-I/home/software/plplot_cvs/HEAD/build_dir/bindings/python -I/usr/include/python2.4
-I/usr/lib/python2.4/site-packages/numpy/core/include/numpy
-I/home/software/plplot_cvs/HEAD/plplot_cmake/bindings/swig-support -o
/home/software/plplot_cvs/HEAD/build_dir/bindings/python/plplotcmodulePYTHON_wrap.c
/home/software/plplot_cvs/HEAD/plplot_cmake/bindings/python/plplotcmodule.i
Scanning dependencies of target _plplotcmodule
cd /home/software/plplot_cvs/HEAD/build_dir /usr/bin/cmake -E cmake_depends Unix
Makefiles /home/software/plplot_cvs/HEAD/plplot_cmake
/home/software/plplot_cvs/HEAD/plplot_cmake/bindings/python
/home/software/plplot_cvs/HEAD/build_dir /home/software/plplot_cvs/HEAD/build_dir/bindings/python
/home/software/plplot_cvs/HEAD/build_dir/bindings/python/CMakeFiles/_plplotcmodule.dir/DependInfo.cmake
make[2]: Leaving directory `/home/software/plplot_cvs/HEAD/build_dir'
make -f bindings/python/CMakeFiles/_plplotcmodule.dir/build.make
bindings/python/CMakeFiles/_plplotcmodule.dir/build
make[2]: Entering directory `/home/software/plplot_cvs/HEAD/build_dir'
/usr/bin/cmake -E cmake_progress_report /home/software/plplot_cvs/HEAD/build_dir/CMakeFiles
[ 9%] Building C object bindings/python/CMakeFiles/_plplotcmodule.dir/plplotcmodulePYTHON_wrap.o
/usr/bin/gcc -D_plplotcmodule_EXPORTS -fPIC
-I/home/software/plplot_cvs/HEAD/plplot_cmake/include
-I/home/software/plplot_cvs/HEAD/build_dir
-I/home/software/plplot_cvs/HEAD/build_dir/include
-I/home/software/plplot_cvs/HEAD/build_dir/bindings/python
-I/usr/include/python2.4
-I/usr/lib/python2.4/site-packages/numpy/core/include/numpy
-I/home/software/plplot_cvs/HEAD/plplot_cmake/bindings/swig-support
-DHAVE_CONFIG_H -o
bindings/python/CMakeFiles/_plplotcmodule.dir/plplotcmodulePYTHON_wrap.o -c
/home/software/plplot_cvs/HEAD/build_dir/bindings/python/plplotcmodulePYTHON_wrap.c
/home/software/plplot_cvs/HEAD/build_dir/bindings/python/plplotcmodulePYTHON_wrap.c:2510:1:
warning: PySequence_Fast_GET_ITEM redefined
In file included from /usr/include/python2.4/Python.h:123,
from
Re: [CMake] Swig dependencies not being tested?
Am Montag 10 Dezember 2007 schrieb Tristan Carel:
On Dec 10, 2007 7:15 AM, Alan W. Irwin [EMAIL PROTECTED] wrote:
On 2007-12-10 05:33+0100 Christiaan Putter wrote:
Hi all,
I know swig support isn't all that great at the moment but was
wondering if someone happens to have a working Swig module for cmake
that doesn't rebuild every time even without the dependencies having
changed.
I do confirm that is a problem, and I hope somebody fixes it.
I use the Swig module, the one provided by CMake, and it's working
well. Swig wrappers generation and library compilation are properly
managed (not rebuild all the time). I use it the same way than Alan
described: only one swig file, which takes care of all inclusions, is
provided to the macro SWIG_ADD_MODULE. To specify missing
dependencies, I use the variable `SWIG_MODULE_module_EXTRA_DEPS':
SET(SWIG_MODULE_foo_EXTRA_DEPS bar.i foobar.i bar.h ...)
SWIG_ADD_MODULE(foo PYTHON foo.i)
And there is the whole point: that adds a cmake target foo with output
name _foo.so. So an
SWIG_ADD_MODULE(foo PERL foo.i)
conflicts with the first cmake target. Add even an
SWIG_ADD_MODULE(foo RUBY foo.i)
conflict with the cmake target _and_ the output name of the PERL line. That
could be improved a lot.
The following recompiles every time:
---snip
option ( BUILD_BINDINGS Build the SWIG bindings )
if ( BUILD_BINDINGS )
find_package ( SWIG REQUIRED )
include (${SWIG_USE_FILE})
include_directories ( ${CMAKE_CURRENT_SOURCE_DIR} )
set ( FOO_SWIG_FILE ${CMAKE_CURRENT_SOURCE_DIR}/foo.i )
set ( CMAKE_SWIG_FLAGS )
set_source_files_properties ( ${FOO_SWIG_FILE} PROPERTIES
CPLUSPLUS OFF
SWIG_FLAGS
)
foreach ( LANG perl python ruby )
string ( TOUPPER ${LANG} LANG_UPPERCASE)
option ( BUILD_${LANG_UPPERCASE}_BINDING Build the ${LANG} binding ON )
include ( ${LANG}/CMakeLists.txt)
endforeach ( LANG )
endif ( BUILD_BINDINGS )
---snip
The python/CMakelists.txt then contains:
---snip
find_package ( PythonLibs )
include_directories ( ${PYTHON_INCLUDE_PATH} )
swig_add_module ( foo_python python ${FOO_SWIG_FILE} )
swig_link_libraries ( foo_python libobexftp )
set_target_properties ( ${SWIG_MODULE_foo_python_REAL_NAME}
PROPERTIES
OUTPUT_NAME _foo
)
---snip
You have your example :)
The same for PERL does _not_ recompile every time.
Attached to #4147, you can find a macro
`SWIG_GET_WRAPPER_DEPENDENCIES' which use -MM option provided by Swig
to compute dependencies. This intend to replace use of variable
SWIG_MODULE_module_EXTRA_DEPS
Could you please describe a use case which create the unnecessary
rebuilt of your project?
Someone else also pointed out a problem with .i files having to be in
the current source dir.
We have never felt constrained by that limitation (in fact I was unaware
of it) since it is possible to specify just one *.i file in the current
source directory that then includes *.i files from elsewhere in the
source tree.
Despite the convenience of this approach, others will have different
needs that would best be served by allowing the initial *.i file (that
includes the rest of the *.i files) to be somewhere else than the current
source directory so on these general grounds I hope this limitation is
removed at the same time as when the dependency problem is fixed.
I agree, it should work.
I guess it is alright if you specify a path like ../common.i but not
something like ${CMAKE_SOURCE_DIR}/swig/common.i.
No, neither works currently.
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.4.7 -- ld: Can't find library or mismatched ABI for -lgcc
I've attached make VERBOSE=1 outputPlease help!
Thank you.
Jennifer
make
in dir /home/builder/builds/hpux_i/dsc_hpux_i/build (timeout 1200 secs)
watching logfiles {}
argv: ['make']
environment:
ERASE=^H
HOME=/home/builder/builds
LOGNAME=builder
MAIL=/var/mail/builder
MANPATH=/usr/share/man/%L:/usr/share/man:/usr/contrib/man/%L:/usr/contrib/man:/usr/local/man/%L:/usr/local/man:/opt/ldapux/share/man/%L:/opt/ldapux/share/man:/opt/ipf/man:/opt/ldapux/ypldapd/man:/opt/samba/man:/opt/samba/WTEC_Support_Tools/man:/opt/samba/cfsm_man:/opt/cifsclient/share/man:/opt/rdma/share/man:/opt/openssl/man:/opt/openssl/prngd/man:/opt/wbem/share/man:/opt/hpsmdb/pgsql/man:/opt/ssh/share/man:/opt/mx/share/man/%L:/opt/mx/share/man:/opt/graphics/common/man:/opt/amgr/man:/opt/amgr/man/%L:/opt/sec_mgmt/share/man:/usr/dt/share/man:/opt/drd/share/man/%L:/opt/drd/share/man:/opt/dsau/man:/opt/resmon/share/man/%L:/opt/resmon/share/man:/opt/gnome/man:/opt/perf/man/%L:/opt/perf/man:/opt/ignite/share/man/%L:/opt/ignite/share/man:/usr/contrib/kwdb/share/man:/opt/perl_32/man:/opt/perl_64/man:/opt/prm/man/%L:/opt/prm/man:/opt/sfmdb/pgsql/man:/opt/sfm/share/man:/opt/swm/share/man/%L:/opt/swm/share/man:/opt/sec_mgmt/share/man/%L:/opt/spb/share/man:/opt/swa/share/man/%L:/opt
/swa/share/man:/opt/VRTS/man:/opt/gwlm/man/%L:/opt/gwlm/man:/opt/aCC/share/man/%L:/opt/langtools/share/man/%L:/opt/langtools/share/man:/opt/imake/man:/opt/aCC/share/man:/opt/vse/man/%L:/opt/caliper/man/%L:/opt/caliper/man:/opt/cadvise/share/man/%L:/opt/cadvise/share/man:/opt/sentinel/man/%L:/opt/sentinel/man:/opt/hp-gcc/man
OLDPWD=/home/builder/builds/hpux_i/dsc_hpux_i
PATH=/usr/bin:/usr/ccs/bin:/usr/contrib/bin:/usr/contrib/Q4/bin:/opt/perl/bin:/opt/ipf/bin:/opt/nettladm/bin:/opt/fcms/bin:/opt/wbem/bin:/opt/wbem/sbin:/opt/rdma/bin:/opt/sas/bin:/opt/ssh/bin:/opt/mx/bin:/opt/graphics/common/bin:/opt/atok/bin:/usr/bin/X11:/usr/contrib/bin/X11:/opt/sec_mgmt/bastille/bin:/opt/drd/bin:/opt/dsau/bin:/opt/dsau/sbin:/opt/resmon/bin:/opt/firefox:/opt/gnome/bin:/opt/perf/bin:/opt/ignite/bin:/usr/contrib/kwdb/bin:/opt/mozilla:/var/opt/netscape/server7/shared/bin:/var/opt/netscape/server7/bin:/opt/perl_32/bin:/opt/perl_64/bin:/opt/prm/bin:/opt/sfm/bin:/opt/swm/bin:/opt/sec_mgmt/spc/bin:/opt/java1.4/jre/bin:/opt/spb/bin:/opt/swa/bin:/opt/hpsmh/bin:/opt/thunderbird:/opt/gwlm/bin:/opt/aCC/bin:/opt/langtools/bin:/opt/vse/bin:/opt/caliper/bin:/opt/cadvise/bin:/opt/sentinel/bin:/opt/hp-gcc/bin:/usr/local/bin
PWD=/home/builder/builds/hpux_i
SFTP_PERMIT_CHMOD=1
SFTP_PERMIT_CHOWN=1
SFTP_UMASK=
SHELL=/usr/local/bin/bash
SHLVL=1
SSH_CLIENT=10.18.0.94 1870 22
SSH_CONNECTION=10.18.0.94 1870 10.18.0.61 22
SSH_TTY=/dev/pts/0
TERM=xterm
TZ=MST7MDT
USER=builder
_=/usr/local/bin/buildbot
/usr/local/bin/cmake
-H/home/builder/builds/hpux_i/dsc_hpux_i/svn
-B/home/builder/builds/hpux_i/dsc_hpux_i/build --check-build-system
CMakeFiles/Makefile.cmake 0
/usr/local/bin/cmake -E cmake_progress_start
/home/builder/builds/hpux_i/dsc_hpux_i/build/CMakeFiles 100
make -f CMakeFiles/Makefile2 all
make -f src/helpc/CMakeFiles/helpc.dir/build.make
src/helpc/CMakeFiles/helpc.dir/depend
make -f src/helpc/CMakeFiles/helpc.dir/build.make
src/helpc/CMakeFiles/helpc.dir/build
Linking C executable ../../bin/helpc
cd /home/builder/builds/hpux_i/dsc_hpux_i/build/src/helpc
/usr/local/bin/cmake -P CMakeFiles/helpc.dir/cmake_clean_target.cmake
cd /home/builder/builds/hpux_i/dsc_hpux_i/build/src/helpc
/usr/bin/cc -DSTDH -D_HPUX_SOURCE -D_UNIX -DHPUX
+W2111,2177,2186,2250,2261,2550,4227,4255 +Z +w +W229 +W361 +W392
+W431 +W655 +W684 +W818 +W819 +W849 +W889 -Wl,+vnocompatwarnings
-Wl,+s CMakeFiles/helpc.dir/hci18n.o CMakeFiles/helpc.dir/hcio.o
CMakeFiles/helpc.dir/hcmain.o CMakeFiles/helpc.dir/hcnn.o
CMakeFiles/helpc.dir/hcpm.o CMakeFiles/helpc.dir/hcpp.o
CMakeFiles/helpc.dir/hcstr.o CMakeFiles/helpc.dir/hcwin.o
CMakeFiles/helpc.dir/hcstub.o CMakeFiles/helpc.dir/ustr.o
CMakeFiles/helpc.dir/home/builder/builds/hpux_i/dsc_hpux_i/svn/src/ptk/cpatches.o
CMakeFiles/helpc.dir/home/builder/builds/hpux_i/dsc_hpux_i/svn/src/ptk/huerr.o
CMakeFiles/helpc.dir/home/builder/builds/hpux_i/dsc_hpux_i/svn/src/ptk/hulist.o
CMakeFiles/helpc.dir/home/builder/builds/hpux_i/dsc_hpux_i/svn/src/ptk/humem.o
CMakeFiles/helpc.dir/home/builder/builds/hpux_i/dsc_hpux_i/svn/src/
ptk/hustr.o -o ../../bin/helpc -Wl,+s -Wl,-E -L.
-L/home/builder/builds/hpux_i/dsc_hpux_i/svn/lib
/usr/local/bin/cmake -E cmake_progress_report
/home/builder/builds/hpux_i/dsc_hpux_i/build/CMakeFiles 1 2 3
[ 3%] Built target helpc
make -f src/curl/CMakeFiles/curl.dir/build.make
src/curl/CMakeFiles/curl.dir/depend
make -f src/curl/CMakeFiles/curl.dir/build.make
src/curl/CMakeFiles/curl.dir/build
Linking C executable ../../bin/curl
cd /home/builder/builds/hpux_i/dsc_hpux_i/build/src/curl
/usr/local/bin/cmake -P
Re: [CMake] cmake 2.4.8 RC 4
Can this be fixed for 2.4.8? It looks like it was already fixed for 2.6, but I couldn't find a bug report for it. = ADD_LIBRARY(A a.c) ADD_LIBRARY(Ad a.c) ADD_LIBRARY(B b.c) TARGET_LINK_LIBRARIES(B debug Ad optimized A) # if building shared libs, cmake correctly links B with -lAd OR -lA ADD_EXECUTABLE(C c.c) TARGET_LINK_LIBRARIES(C B) # cmake incorrectly links C with -lB -lAd -lA if build type is Debug === Clint On Wednesday 05 December 2007 3:13:39 pm Bill Hoffman wrote: I have a beta release for 2.4.8 ready for cmake. This will be the last release of the 2.4.X branch. The next release will be 2.6.0. So, please make sure you test it if you are interested in a 2.4.8. Send any issues to me or the cmake list. Thanks. The files can be found here: http://www.cmake.org/files/v2.4/*RC-4* The changes from 2.4.7 are as follows: Changes in CMake 2.4.8 RC 4 * fix for cpack and messing up PATH with NSIS Changes in CMake 2.4.8 RC 3 * fix for bug 5363: GET_TARGET_PROPERTY(... DEBUG_LOCATION) returns value containing $(OutDir) * Better error from ctest if nightly time not set * Fix for exception handling flags in VS 2003 and up * Avoid relinking exclude-from-all directory targets before install Changes in CMake 2.4.8 RC 2 * fix for bug 5590 relative paths in windows not working across drives * fix warning/error with TAR_VERBOSE flag Changes in CMake 2.4.8 RC 1 * Fix for kde4-config location * Fix for self extracting .sh files on solaris * Remove KDE3_ENABLE_FINAL (did not work) * KDE3 fix for 64 bit location of plugins * mark PYTHON_EXECUTABLE as advanced * Fix for version numbers on NetBSD * Add more search directories (install prefix and cmake location) * include WindowsPaths in Windows.cmake not just Windows-cl.cmake * documentation fix for file, find_package, try_run * add IS_ABSOLUTE to if * INSTALL() everything which doesn't have a COMPONENT set, is assigned to the COMPONENT Unspecified * make #cmakedefine output match autoconf when undefined * document cmake remove -f * document order of -D and -P * add support for DragonFly and GNU hurd * fix for fortran depends doing too many scans ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] function and raise_scope commands
Thanks for the information. Both these issues I suspect are fairly simple
bugs and will be fixed.
Thanks
Ken
1. CMake crashes if I use the same variable name as the argument and
raise the scope later. That is, for the following function:
function(track_find_variable cache_variable is_changed)
raise_scope(${is_changed})
endfunction(track_find_variable)
I can't call it like:
track_find_variable(testvar is_changed) # I had to mangle is_changed
above, but that's ok
I think it shouldn't crash. If its too much effort to have cmake
support this, then I don't think it is worth it... just having a note
that the argument can't be used as a variable name in the help and
maybe try to detect the case and signal an error...
2. Given the new scope contexts, when I call the following function:
function(tester)
message(STATUS ${CMAKE_CURRENT_LIST_FILE})
endfunction(tester)
tester() prints what it should:
D:/builds/temp/testLatexModule/CMakeLists.txt
However, if I put it in a cmake_utils.cmake file and call
include(cmake_utils):
tester() prints garbage... somehow it gets corrupted. For example, in
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] question about clock skew detected. Your build may be incomplete
WangPing wrote: The date /time on my local workstation is correct, probably due to NFS system, Do you mean NTP? NFS does not keep your local computer time correct. the work directory is a NFS folder on other server, maybe the date/time on this server is incorrect? I can check it later. NFS is probably the *primary* cause of clock skew, and GNU make can be pretty picky about how close the clocks need to be. (Note that a local clock which is out-of-date won't cause clock skew in itself, since everything will be out-of-date by the same amount.) Also note that if the build succeeds, you probably have nothing to worry about. (Unless you're hacking in the code yourself, then make may have failed to rebuild any out-of-date files.) -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: [Insight-users] question about clock skew detected. Your build may be incomplete
Karthik Krishnan wrote:
Your system time is probably incorrect. One possible reason is that the
timestamp of the files that make is compiling is newer than the current
time.
If the local time is correct and no network filesystems are involved,
then I would guess that there is a file somewhere with a modification
time in the future, but GNU make will notify the user if that is the case:
$ make
cc foo.c -o foo
$ touch --date=tomorrow foo.c
$ make
make: Warning: File `foo.c' has modification time 8.6e+04 s in the future
cc foo.c -o foo
make: warning: Clock skew detected. Your build may be incomplete.
WangPing, can you reproduce this with a trivial makefile?
Makefile:
foo: foo.c
$(CC) $ -o $@
foo.c:
int main() { return 0; }
This does not sound CMake-related to me.
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Renaming Directories
Hello, Can someone suggest a way to have a directory renamed after it has been installed with the install command? Thanks , Josh ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] HPUX 11.31 lgcc error
Hi all, I need desperate help with my CMake and was hoping someone could render assistance. I'm running HP-UX 11.31 ia64 and compiled CMake using aCC (HP Native Compiler). When I attempt to compile my code, I receive the following error: [ 26%] Built target XmHTML make -f src/ptk/CMakeFiles/xvtxmba580.dir/build.make src/ptk/CMakeFiles/xvtxmba580.dir/depend make -f src/ptk/CMakeFiles/xvtxmba580.dir/build.make src/ptk/CMakeFiles/xvtxmba580.dir/build Linking C shared library ../../lib/libxvtxmba580.sl cd /home/builder/builds/hpux_i/dsc_hpux_i/build/src/ptk /usr/local/bin/cmake -P CMakeFiles/xvtxmba580.dir/cmake_clean_target.cmake cd /home/builder/builds/hpux_i/dsc_hpux_i/build/src/ptk /usr/local/bin/cmake -E cmake_link_script CMakeFiles/xvtxmba580.dir/link.txt --verbose=1 ld -E -b -L/usr/lib +hlibxvtxmba580.sl -o ../../lib/libxvtxmba580.sl CMakeFiles/xvtxmba580.dir/vanywin.o CMakeFiles/xvtxmba580.dir/vapp.o CMakeFiles/xvtxmba580.dir/vcnames.o CMakeFiles/xvtxmba580.dir/vcolor.o CMakeFiles/xvtxmba580.dir/vctable.o CMakeFiles/xvtxmba580.dir/vctl.o CMakeFiles/xvtxmba580.dir/vcxo.o CMakeFiles/xvtxmba580.dir/vdebug.o CMakeFiles/xvtxmba580.dir/vdlist.o CMakeFiles/xvtxmba580.dir/vdm.o CMakeFiles/xvtxmba580.dir/vdwin.o CMakeFiles/xvtxmba580.dir/verrmsg.o CMakeFiles/xvtxmba580.dir/verrtxt.o CMakeFiles/xvtxmba580.dir/vevent.o CMakeFiles/xvtxmba580.dir/vfont.o CMakeFiles/xvtxmba580.dir/vfrlin.o CMakeFiles/xvtxmba580.dir/vfrlutil.o CMakeFiles/xvtxmba580.dir/vfsys.o CMakeFiles/xvtxmba580.dir/vgmem.o CMakeFiles/xvtxmba580.dir/vhash.o CMakeFiles/xvtxmba580.dir/vhtml.o CMakeFiles/xvtxmba580.dir/vidmap.o CMakeFiles/xvtxmba580.dir/vimage.o CMakeFiles/xvtxmba580.dir/vimgbmpr.o CMakeFiles/xvtxmba580.dir/vimgbmpw. o CMakeFiles/xvtxmba580.dir/vimggif.o CMakeFiles/xvtxmba580.dir/vimgjpg.o CMakeFiles/xvtxmba580.dir/vimgmac.o CMakeFiles/xvtxmba580.dir/vimgxbm.o CMakeFiles/xvtxmba580.dir/vimgxfer.o CMakeFiles/xvtxmba580.dir/vimgxpm.o CMakeFiles/xvtxmba580.dir/viostr.o CMakeFiles/xvtxmba580.dir/vlist.o CMakeFiles/xvtxmba580.dir/vmem.o CMakeFiles/xvtxmba580.dir/vnav.o CMakeFiles/xvtxmba580.dir/vnotebk.o CMakeFiles/xvtxmba580.dir/vpalet.o CMakeFiles/xvtxmba580.dir/vpat.o CMakeFiles/xvtxmba580.dir/vrect.o CMakeFiles/xvtxmba580.dir/vres.o CMakeFiles/xvtxmba580.dir/vresread.o CMakeFiles/xvtxmba580.dir/vscr.o CMakeFiles/xvtxmba580.dir/vslist.o CMakeFiles/xvtxmba580.dir/vstr.o CMakeFiles/xvtxmba580.dir/vstatic.o CMakeFiles/xvtxmba580.dir/vtreev.o CMakeFiles/xvtxmba580.dir/vvobj.o CMakeFiles/xvtxmba580.dir/vwin.o CMakeFiles/xvtxmba580.dir/xm/kapp.o CMakeFiles/xvtxmba580.dir/xm/kdwin.o CMakeFiles/xvtxmba580.dir/xm/kfont.o CMakeFiles/xvtxmba580.dir /xm/kfsys.o CMakeFiles/xvtxmba580.dir/xm/khtml.o CMakeFiles/xvtxmba580.dir/xm/kicon.o CMakeFiles/xvtxmba580.dir/xm/kimage.o CMakeFiles/xvtxmba580.dir/xm/kmenu.o CMakeFiles/xvtxmba580.dir/xm/kmultih.o CMakeFiles/xvtxmba580.dir/xm/knotebk.o CMakeFiles/xvtxmba580.dir/xm/kpalet.o CMakeFiles/xvtxmba580.dir/xm/kpict.o CMakeFiles/xvtxmba580.dir/xm/kpmap.o CMakeFiles/xvtxmba580.dir/xm/krect.o CMakeFiles/xvtxmba580.dir/xm/kstr.o CMakeFiles/xvtxmba580.dir/xm/ktext.o CMakeFiles/xvtxmba580.dir/xm/ktimer.o CMakeFiles/xvtxmba580.dir/xm/kvobj.o CMakeFiles/xvtxmba580.dir/xm/kwin.o CMakeFiles/xvtxmba580.dir/xm/xCaret.o CMakeFiles/xvtxmba580.dir/xm/xCursor.o CMakeFiles/xvtxmba580.dir/xm/xDispatch.o CMakeFiles/xvtxmba580.dir/xm/xMisc.o CMakeFiles/xvtxmba580.dir/xm/xQueue.o CMakeFiles/xvtxmba580.dir/xm/xTrace.o CMakeFiles/xvtxmba580.dir/xm/xUpdate.o CMakeFiles/xvtxmba580.dir/xm/xWinUtil.o CMakeFiles/xvtxmba580.dir/xm/xhtml.o CMakeFiles/xvtxmba580 .dir/xm/xmAttr.o CMakeFiles/xvtxmba580.dir/xm/xmAttrTbl.o CMakeFiles/xvtxmba580.dir/xm/xmCb.o CMakeFiles/xvtxmba580.dir/xm/xmControl.o CMakeFiles/xvtxmba580.dir/xm/xmDialog.o CMakeFiles/xvtxmba580.dir/xm/xmEscape.o CMakeFiles/xvtxmba580.dir/xm/xmEvent.o CMakeFiles/xvtxmba580.dir/xm/xmFocus.o CMakeFiles/xvtxmba580.dir/xm/xmFontSel.o CMakeFiles/xvtxmba580.dir/xm/xmInit.o CMakeFiles/xvtxmba580.dir/xm/xmMenu.o CMakeFiles/xvtxmba580.dir/xm/xmPatches.o CMakeFiles/xvtxmba580.dir/xm/xmPopup.o CMakeFiles/xvtxmba580.dir/xm/xmRes.o CMakeFiles/xvtxmba580.dir/xm/xmWinUtil.o CMakeFiles/xvtxmba580.dir/xm/xmWindow.o CMakeFiles/xvtxmba580.dir/xm/xsrinit.o CMakeFiles/xvtxmba580.dir/xm/xsrman.o CMakeFiles/xvtxmba580.dir/xm/xssel.o CMakeFiles/xvtxmba580.dir/xm/xxinit.o CMakeFiles/xvtxmba580.dir/xm/vfpath.o CMakeFiles/xvtxmba580.dir/xm/vprint.o CMakeFiles/xvtxmba580.dir/xm/vprps.o CMakeFiles/xvtxmba580.dir/cpatches.o CMakeFiles/xvtxmba580.dir/jpeg/j capimin.o CMakeFiles/xvtxmba580.dir/jpeg/jcapistd.o CMakeFiles/xvtxmba580.dir/jpeg/jccoefct.o CMakeFiles/xvtxmba580.dir/jpeg/jccolor.o CMakeFiles/xvtxmba580.dir/jpeg/jcdctmgr.o CMakeFiles/xvtxmba580.dir/jpeg/jchuff.o CMakeFiles/xvtxmba580.dir/jpeg/jcinit.o CMakeFiles/xvtxmba580.dir/jpeg/jcmainct.o CMakeFiles/xvtxmba580.dir/jpeg/jcmarker.o CMakeFiles/xvtxmba580.dir/jpeg/jcmaster.o
Re: [CMake] Renaming Directories
INSTALL(DIRECTORY ... can change the name if your source has a trailing '/' but the destination doesn't. Clint On Dec 10, 2007, at 4:46 PM, Josh Schulte wrote: Hello, Can someone suggest a way to have a directory renamed after it has been installed with the install command? Thanks , Josh ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] escaping!
Is it possible to have a command like this?
ADD_CUSTOM_COMMAND(OUTPUT ${my_file}
...
COMMAND find . -name *xml /dev/null
...
VERBATIM
)
Not sure if you got a reply to this, nor if the following is any help, BUT...
For any tricky file operations (like all files ending with XML greater than
2Kb using DOS newlines etc) I would personally write a python script (e.g.
ROOTDIR/util/xmlfinder.py) to do that work and make the command simply invoke
the python script. This has the added advantage of being cross-platform as
well, keeping the CMakeLists.txt file simpler.
HTH
Andrew
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] escaping!
Am Dienstag 11 Dezember 2007 schrieb Andrew Roark:
Is it possible to have a command like this?
ADD_CUSTOM_COMMAND(OUTPUT ${my_file}
...
COMMAND find . -name *xml /dev/null
...
VERBATIM
)
Not sure if you got a reply to this, nor if the following is any help,
BUT...
For any tricky file operations (like all files ending with XML greater
than 2Kb using DOS newlines etc) I would personally write a python script
(e.g. ROOTDIR/util/xmlfinder.py) to do that work and make the command
simply invoke the python script. This has the added advantage of being
cross-platform as well, keeping the CMakeLists.txt file simpler.
I never saw a Windows system with an installed Python. Strange isn't it ;)
find wasn't present either, though...
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Including of Platform/UnixPaths.cmake now broken
This used to work properly, but it has now changed behavior and is now
borken.
Using CVS version, somewhat latest one.
cmake version 2.5-20071026
I have:
SET( CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/modules )
to change cmake's search path behavior.
Inside my local modules dir, I have Platform/UnixPaths.cmake, to fix
cmake's searching of 32-bit stuff on a 64-bit machine when -m32 is used.
I use my own variable -DCMAKE_BUILD_ARCH=32 to determine whether I am
compiling 32-bits on a 64-bits machine.
The problem is that cmake now goes to check compiler and it runs
Platform/UnixPaths.cmake without passing any of my variables to it (ie.
CMAKE_BUILD_ARCH=).
Then, after it calls the compiler check, it seems it caches the
CMAKE_SYSTEM_PATH and does not call Platform/UnixPaths anymore during
the running of my CMakeLists.txt file.
Other local modules do get picked correctly with my variables set, so
CMAKE_MODULE_PATH works ok, but not for Platform/UnixPaths.cmake.
This results in CMAKE_SYSTEM_PATH being set wrong (and thus, my compile
not to work).
Previous versions would invoke UnixPaths.cmake multiple times, so even
though the compiler check would call it wrongly without any variable
set, during the course of my actual run of the CMakeLists.txt file, it
would get called again but with my vars set, which allowed me to set the
path correctly.
I'm either looking for:
a) A correct UnixPaths.cmake module that handles 32-bits libs properly
(the current one in CVS does not).
or
b) A fix to this broken behavior.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] HPUX 11.31 lgcc error
Am Dienstag 11 Dezember 2007 schrieb [EMAIL PROTECTED]: Hi all, I need desperate help with my CMake and was hoping someone could render assistance. I'm running HP-UX 11.31 ia64 and compiled CMake using aCC (HP Native Compiler). When I attempt to compile my code, I receive the following error: [...] The GCC man page mentions libgcc alot. Do you actually use acc or gcc on your system? Maybe one of the cmake script include the -lgcc even when you use acc. A bug then, I guess. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] escaping!
- Original Message
From: Hendrik Sattler [EMAIL PROTECTED]
To: cmake@cmake.org
Sent: Monday, December 10, 2007 7:29:21 PM
Subject: Re: [CMake] escaping!
Am Dienstag 11 Dezember 2007 schrieb Andrew Roark:
Is it possible to have a command like this?
ADD_CUSTOM_COMMAND(OUTPUT ${my_file}
...
COMMAND find . -name *xml /dev/null
...
VERBATIM
)
Not sure if you got a reply to this, nor if the following is
any
help,
BUT...
For any tricky file operations (like all files ending with
XML
greater
than 2Kb using DOS newlines etc) I would personally write a
python
script
(e.g. ROOTDIR/util/xmlfinder.py) to do that work and make the command
simply invoke the python script. This has the added advantage
of
being
cross-platform as well, keeping the CMakeLists.txt file simpler.
I never saw a Windows system with an installed Python. Strange isn't
it
;)
I see -- you're using one of those Windows systems that comes pre-installed
with CMake?...
Andrew
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] escaping!
On Dec 10, 2007 7:12 PM, Andrew Roark [EMAIL PROTECTED] wrote: For any tricky file operations (like all files ending with XML greater than 2Kb using DOS newlines etc) I would personally write a python script (e.g. ROOTDIR/util/xmlfinder.py) to do that work and make the command simply invoke the python script. I simply learned how to do everything in CMake script. File input / output and regular expressions are certainly quite doable, there's no reason to use Python for that. Or Perl, Ruby, grep, awk, or sed for that matter. Lately I've written a lot of translation code to get rid of those tools. This has the added advantage of being cross-platform as well, keeping the CMakeLists.txt file simpler. I'm quite jaded about keeping CMakeLists.txt simple. As far as I'm concerned, it should be as simple as the level of complication of your build. If I want encapsulation, I write a macro. Otherwise I'll just write straight CMake script, because I'd rather read CMake script than the docs of 5 different Unixy tools that all do their own kind of regular expression processing. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] HPUX 11.31 lgcc error
I use aCC. On Dec 10, 2007 7:51 PM, Hendrik Sattler [EMAIL PROTECTED] wrote: Am Dienstag 11 Dezember 2007 schrieb [EMAIL PROTECTED]: Hi all, I need desperate help with my CMake and was hoping someone could render assistance. I'm running HP-UX 11.31 ia64 and compiled CMake using aCC (HP Native Compiler). When I attempt to compile my code, I receive the following error: [...] The GCC man page mentions libgcc alot. Do you actually use acc or gcc on your system? Maybe one of the cmake script include the -lgcc even when you use acc. A bug then, I guess. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] libxml2
Hi, Could some please show me the proper way to handle libxml2 on Gentoo linux. In my CMakeLists.txt, if I include the following line it works on windows and some versions of linux: TARGET_LINK_LIBRARIES( my_exe ITKCommon ITKIO libxml2) However, when trying to compile on Gentoo linux (using gcc 4.1.2) it complains about not being able to find libxml2.so for linking, unless I change it to: TARGET_LINK_LIBRARIES( my_exe ITKCommon ITKIO xml2) Any advice is appreciated. Charlene ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] HPUX 11.31 lgcc error
[EMAIL PROTECTED] wrote: Hi all, I need desperate help with my CMake and was hoping someone could render assistance. I'm running HP-UX 11.31 ia64 and compiled CMake using aCC (HP Native Compiler). When I attempt to compile my code, I receive the following error: [ 26%] Built target XmHTML make -f src/ptk/CMakeFiles/xvtxmba580.dir/build.make src/ptk/CMakeFiles/xvtxmba580.dir/depend make -f src/ptk/CMakeFiles/xvtxmba580.dir/build.make src/ptk/CMakeFiles/xvtxmba580.dir/build Linking C shared library ../../lib/libxvtxmba580.sl cd /home/builder/builds/hpux_i/dsc_hpux_i/build/src/ptk /usr/local/bin/cmake -P CMakeFiles/xvtxmba580.dir/cmake_clean_target.cmake cd /home/builder/builds/hpux_i/dsc_hpux_i/build/src/ptk /usr/local/bin/cmake -E cmake_link_script CMakeFiles/xvtxmba580.dir/link.txt --verbose=1 ld -E -b -L/usr/lib +hlibxvtxmba580.sl -o ../../lib/libxvtxmba580.sl CMakeFiles/xvtxmba580.dir/vanywin.o CMakeFiles/xvtxmba580.dir/vapp.o CMakeFiles/xvtxmba580.dir/vcnames.o CMakeFiles/xvtxmba580.dir/vcolor.o CMakeFiles/xvtxmba580.dir/vctable.o CMakeFiles/xvtxmba580.dir/vctl.o CMakeFiles/xvtxmba580.dir/vcxo.o CMakeFiles/xvtxmba580.dir/vdebug.o CMakeFiles/xvtxmba580.dir/vdlist.o CMakeFiles/xvtxmba580.dir/vdm.o CMakeFiles/xvtxmba580.dir/vdwin.o CMakeFiles/xvtxmba580.dir/verrmsg.o CMakeFiles/xvtxmba580.dir/verrtxt.o CMakeFiles/xvtxmba580.dir/vevent.o CMakeFiles/xvtxmba580.dir/vfont.o CMakeFiles/xvtxmba580.dir/vfrlin.o CMakeFiles/xvtxmba580.dir/vfrlutil.o CMakeFiles/xvtxmba580.dir/vfsys.o CMakeFiles/xvtxmba580.dir/vgmem.o CMakeFiles/xvtxmba580.dir/vhash.o CMakeFiles/xvtxmba580.dir/vhtml.o CMakeFiles/xvtxmba580.dir/vidmap.o CMakeFiles/xvtxmba580.dir/vimage.o CMakeFiles/xvtxmba580.dir/vimgbmpr.o CMakeFiles/xvtxmba580.dir/vimgbmpw. o CMakeFiles/xvtxmba580.dir/vimggif.o CMakeFiles/xvtxmba580.dir/vimgjpg.o CMakeFiles/xvtxmba580.dir/vimgmac.o CMakeFiles/xvtxmba580.dir/vimgxbm.o CMakeFiles/xvtxmba580.dir/vimgxfer.o CMakeFiles/xvtxmba580.dir/vimgxpm.o CMakeFiles/xvtxmba580.dir/viostr.o CMakeFiles/xvtxmba580.dir/vlist.o CMakeFiles/xvtxmba580.dir/vmem.o CMakeFiles/xvtxmba580.dir/vnav.o CMakeFiles/xvtxmba580.dir/vnotebk.o CMakeFiles/xvtxmba580.dir/vpalet.o CMakeFiles/xvtxmba580.dir/vpat.o CMakeFiles/xvtxmba580.dir/vrect.o CMakeFiles/xvtxmba580.dir/vres.o CMakeFiles/xvtxmba580.dir/vresread.o CMakeFiles/xvtxmba580.dir/vscr.o CMakeFiles/xvtxmba580.dir/vslist.o CMakeFiles/xvtxmba580.dir/vstr.o CMakeFiles/xvtxmba580.dir/vstatic.o CMakeFiles/xvtxmba580.dir/vtreev.o CMakeFiles/xvtxmba580.dir/vvobj.o CMakeFiles/xvtxmba580.dir/vwin.o CMakeFiles/xvtxmba580.dir/xm/kapp.o CMakeFiles/xvtxmba580.dir/xm/kdwin.o CMakeFiles/xvtxmba580.dir/xm/kfont.o CMakeFiles/xvtxmba580.dir /xm/kfsys.o CMakeFiles/xvtxmba580.dir/xm/khtml.o CMakeFiles/xvtxmba580.dir/xm/kicon.o CMakeFiles/xvtxmba580.dir/xm/kimage.o CMakeFiles/xvtxmba580.dir/xm/kmenu.o CMakeFiles/xvtxmba580.dir/xm/kmultih.o CMakeFiles/xvtxmba580.dir/xm/knotebk.o CMakeFiles/xvtxmba580.dir/xm/kpalet.o CMakeFiles/xvtxmba580.dir/xm/kpict.o CMakeFiles/xvtxmba580.dir/xm/kpmap.o CMakeFiles/xvtxmba580.dir/xm/krect.o CMakeFiles/xvtxmba580.dir/xm/kstr.o CMakeFiles/xvtxmba580.dir/xm/ktext.o CMakeFiles/xvtxmba580.dir/xm/ktimer.o CMakeFiles/xvtxmba580.dir/xm/kvobj.o CMakeFiles/xvtxmba580.dir/xm/kwin.o CMakeFiles/xvtxmba580.dir/xm/xCaret.o CMakeFiles/xvtxmba580.dir/xm/xCursor.o CMakeFiles/xvtxmba580.dir/xm/xDispatch.o CMakeFiles/xvtxmba580.dir/xm/xMisc.o CMakeFiles/xvtxmba580.dir/xm/xQueue.o CMakeFiles/xvtxmba580.dir/xm/xTrace.o CMakeFiles/xvtxmba580.dir/xm/xUpdate.o CMakeFiles/xvtxmba580.dir/xm/xWinUtil.o CMakeFiles/xvtxmba580.dir/xm/xhtml.o CMakeFiles/xvtxmba580 .dir/xm/xmAttr.o CMakeFiles/xvtxmba580.dir/xm/xmAttrTbl.o CMakeFiles/xvtxmba580.dir/xm/xmCb.o CMakeFiles/xvtxmba580.dir/xm/xmControl.o CMakeFiles/xvtxmba580.dir/xm/xmDialog.o CMakeFiles/xvtxmba580.dir/xm/xmEscape.o CMakeFiles/xvtxmba580.dir/xm/xmEvent.o CMakeFiles/xvtxmba580.dir/xm/xmFocus.o CMakeFiles/xvtxmba580.dir/xm/xmFontSel.o CMakeFiles/xvtxmba580.dir/xm/xmInit.o CMakeFiles/xvtxmba580.dir/xm/xmMenu.o CMakeFiles/xvtxmba580.dir/xm/xmPatches.o CMakeFiles/xvtxmba580.dir/xm/xmPopup.o CMakeFiles/xvtxmba580.dir/xm/xmRes.o CMakeFiles/xvtxmba580.dir/xm/xmWinUtil.o CMakeFiles/xvtxmba580.dir/xm/xmWindow.o CMakeFiles/xvtxmba580.dir/xm/xsrinit.o CMakeFiles/xvtxmba580.dir/xm/xsrman.o CMakeFiles/xvtxmba580.dir/xm/xssel.o CMakeFiles/xvtxmba580.dir/xm/xxinit.o CMakeFiles/xvtxmba580.dir/xm/vfpath.o CMakeFiles/xvtxmba580.dir/xm/vprint.o CMakeFiles/xvtxmba580.dir/xm/vprps.o CMakeFiles/xvtxmba580.dir/cpatches.o CMakeFiles/xvtxmba580.dir/jpeg/j capimin.o CMakeFiles/xvtxmba580.dir/jpeg/jcapistd.o CMakeFiles/xvtxmba580.dir/jpeg/jccoefct.o CMakeFiles/xvtxmba580.dir/jpeg/jccolor.o CMakeFiles/xvtxmba580.dir/jpeg/jcdctmgr.o CMakeFiles/xvtxmba580.dir/jpeg/jchuff.o CMakeFiles/xvtxmba580.dir/jpeg/jcinit.o CMakeFiles/xvtxmba580.dir/jpeg/jcmainct.o CMakeFiles/xvtxmba580.dir/jpeg/jcmarker.o CMakeFiles/xvtxmba580.dir/jpeg/jcmaster.o
Re: [CMake] libxml2
Am Dienstag 11 Dezember 2007 03:24:27 schrieb Charlene Tsai: on windows and some versions of linux: TARGET_LINK_LIBRARIES( my_exe ITKCommon ITKIO libxml2) I wonder that this worked on linux at all. on Gentoo linux TARGET_LINK_LIBRARIES( my_exe ITKCommon ITKIO xml2) This statement is correct. For gcc it will result on compiler parameters like .. -lITKCommon -lITKIO -lxml2 .. and gcc will search for - libxml2.so* - libxml2.a and IIRC - xml.dll on windows. Did you try TARGET_LINK_LIBRARIES( my_exe ITKCommon ITKIO xml2) on the other linux versions and/or windows? Best, -- Maik ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] libxml2
Quoting Charlene Tsai [EMAIL PROTECTED]:
Hi,
Could some please show me the proper way to handle libxml2 on Gentoo
linux. In my CMakeLists.txt, if I include the following line it works
on windows and some versions of linux:
TARGET_LINK_LIBRARIES( my_exe ITKCommon ITKIO libxml2)
However, when trying to compile on Gentoo linux (using gcc 4.1.2) it
complains about not being able to find libxml2.so for linking, unless
I change it to:
TARGET_LINK_LIBRARIES( my_exe ITKCommon ITKIO xml2)
Any advice is appreciated.
You should really read about how libraries and finders work in CMake.
There is a good amount of information in the wiki and the
Documentation section of the website.
For libxml2, this is what you need:
FIND_PACKAGE(LibXml2)
TARGET_LINK_LIBRARIES( my_exe ITKCommon ITKIO ${LIBXML2_LIBRARIES} )
As you are using ITK, your CMakeLists.txt should look like this:
FIND_PACKAGE(ITK REQUIRED)
IF(ITK_FOUND)
INCLUDE(ITK_USE_FILE)
ENDIF(ITK_FOUND)
FIND_PACKAGE(LibXml2 REQUIRED)
...
TARGET_LINK_LIBRARIES( my_exe ITKCommon ITKIO ${LIBXML2_LIBRARIES} )
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
