Re: [CMake] Ignoring command return code in add_custom_command
On Dec 13, 2007 11:05 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > Hi, is there a way to inform cmake that it should ignore the return code > of the command specified with add_custom_command? I want the command to > be successful, even if it returns something different than 0. > > For instance: > add_custom_command(OUTPUT text.cpp COMMAND false) > add_executable(test main.cpp text.cpp) > > I'm using on linux, using Makefiles, and it bails off because 'false' is > returning 1. What if that's an expected behavior? Is there any way to > circumvent this? I think you will need to do a "COMMAND cmake -P myscript.cmake". myscript.cmake should contain an EXECUTE_PROCESS that does what you want, then interprets the return codes however you want. Then you'd message(SEND_ERROR ...) or message(FATAL_ERROR ...) to indicate an abnormal result. There were bugs regarding CMake script return codes once upon a time; hope those were fixed. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Ignoring command return code in add_custom_command
Hi, is there a way to inform cmake that it should ignore the return code of the command specified with add_custom_command? I want the command to be successful, even if it returns something different than 0. For instance: add_custom_command(OUTPUT text.cpp COMMAND false) add_executable(test main.cpp text.cpp) I'm using on linux, using Makefiles, and it bails off because 'false' is returning 1. What if that's an expected behavior? Is there any way to circumvent this? Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Parallel builds do not work correctly when using "cmake -E copy" to copy files
On 2007-12-13 18:45-0800 Alan W. Irwin wrote: Brad, I am struggling with understanding the recursive make system that CMake normally employs so I am having trouble following the complete Makefile logic that my simple example creates. However, CMakeFiles/tclIndex_examples_tcl2.dir/build.make generated by my simple CMake example seems to follow the above OPTION A scenario. Indeed, if I execute that Makefile directly from the commmand line, e.g., make -f CMakeFiles/tclIndex_examples_tcl2.dir/build.make \ CMakeFiles/tclIndex_examples_tcl2.dir/clean make -j 2 -f CMakeFiles/tclIndex_examples_tcl2.dir/build.make \ CMakeFiles/tclIndex_examples_tcl2.dir/build there are never double copy problems, while if I run make clean make -j 2 there are always double copy problems. (You should try this for yourself to be sure you can replicate my experience.) So my current working hypothesis is there is a parallel build issue for OPTION A that CMake artificially introduces when it recursively invokes make (i.e., the result of the above "make -j 2" command). That last sentence was poorly written. Replace it with the following: So my current working hypothesis is there is a parallel build issue for OPTION A that CMake artificially introduces through its generated recursive make system. That generated recursive make system is invoked with the above "make -j 2" command, but bypassed with the "make -j 2 -f CMakeFiles/..." command above. 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
[CMake] Re: [cmake 2.5 CVS] CMAKE_${LANG}_FLAGS is initialized with space
Bill Hoffman escreveu:
> Do you have environment variables CFLAGS and CXXFLAGS set to have just a
> space? Also, what OS/compiler are you using?
No, those variables are empty. Here's my configuration
[EMAIL PROTECTED] ~ $ cmake --version
cmake version 2.5-20071212
[EMAIL PROTECTED] ~ $ echo X${CXXFLAGS}X X${CFLAGS}X
XX XX
[EMAIL PROTECTED] ~ $ uname -a
Linux home 2.6.23-gentoo-r1 #1 SMP Wed Nov 7 21:06:37 BRDT 2007 i686
Intel(R) Pentium(R) 4 CPU 3.20GHz GenuineIntel GNU/Linux
[EMAIL PROTECTED] ~ $ gcc --version
gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0)
Thanks for the quick response.
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Parallel builds do not work correctly when using "cmake -E copy" to copy files
On 2007-12-13 19:15-0500 Brad King wrote: Alan W. Irwin wrote: So the rule seems to be that parallel builds do not work if there are two or more separate custom targets that file depend directly or indirectly (via some custom command file dependency chain) on the same output files. Another way of summarizing these results is that file depends must be minimized and/or custom target depends maximized in order for parallel builds to work properly. This is correct. My guess is I should be able to work around this CMake issue by appropriate changes to the PLplot build system although I have a number of these parallel build issues and the copy problem was only the most obvious. I do regard this as a CMake issue. Normally, the shoe is on the other foot, and the build system developer is desperately trying to make sure that all the CMake file depends are obviously in place locally rather than depending on a long easily-broken chain of dependencies to do it for them in a minimalist way. So the big question is whether CMake can be modified so that minimalist file depends and/or maximal (and unintuitive) target depends are not required in order for parallel builds to work properly. I don't see how CMake can automatically fix this. If two targets think they know how to build the same file how is CMake supposed to know which one is the correct target to build first? I am not completely convinced by that reasoning. Let me create an abstract case in Makefile terms that we can discuss (at first) strictly from the GNU make point of view. Putting my simple test case in Makefile terms we have the following rules: all: target1 target2 file1: custom command to create file1 fileN: custom command to create fileN target1: file1, file2,fileN additional_file: file1, file2,fileN custom command to create additional_file There are two alternatives for the target2 dependencies Either target2: additional_file (OPTION A) or target2: target1 additional_file (OPTION B) all, target1, and target2 arephony targets that do not correspond to actual files. OPTION A is what my simple example (and current PLplot) uses. OPTION B is one fixup you discussed where you made target2 depend on target1. I know OPTION A always works for serial builds. The reason is each target knows independently how to build what it needs. target1 file-depends directly on the files from a variety of file1 through fileN custom rules. So it knows how to build exactly what it needs. target2 (with OPTION A) file-depends on additional_file which file depends on the file1-fileN rules. So target2 knows how to build exactly what it needs as well. Thus, if you remove target1, target2 would build without problems and vice versa. Of course once you introduce parallel builds it gets complicated, and I would appreciate your input on that. I have always assumed that if one processor was busy creating file1 through the target1 chain of dependencies the make command kept track that a build of file1 was in progress so the other processor would not attempt to duplicate that build regardless of whether it needed it via the target1 or target2 dependency chains. Indeed, OPTION A works well for parallel builds (see below where I non-recursively invoke the appropriate Makefile that is generated by CMake). You claim that OPTION B must be used for parallel builds (at least if I have understood you correctly and if my mental model of how cmake dependencies translate to Makefile dependencies is correct). I just don't see the necessity of OPTION B for parallel builds for non-recursive Makefiles, but I am willing to be educated. :-) If GNU make does parallel builds without problems for non-recursive OPTION A (which appears to be the case, see below), then my concern is that CMake is introducing some additional make issues via the make recursion that it normally employs that screws up parallel builds and OPTION B is simply a workaround that bypasses that recursion issue. Brad, I am struggling with understanding the recursive make system that CMake normally employs so I am having trouble following the complete Makefile logic that my simple example creates. However, CMakeFiles/tclIndex_examples_tcl2.dir/build.make generated by my simple CMake example seems to follow the above OPTION A scenario. Indeed, if I execute that Makefile directly from the commmand line, e.g., make -f CMakeFiles/tclIndex_examples_tcl2.dir/build.make \ CMakeFiles/tclIndex_examples_tcl2.dir/clean make -j 2 -f CMakeFiles/tclIndex_examples_tcl2.dir/build.make \ CMakeFiles/tclIndex_examples_tcl2.dir/build there are never double copy problems, while if I run make clean make -j 2 there are always double copy problems. (You should try this for yourself to be sure you can replicate my experience.) So my current working hypothesis is there is a parallel build issue for OPTION A that CMake artificially introduces when it recursively invokes make (i.e., the res
Re: [CMake] [cmake 2.5 CVS] CMAKE_${LANG}_FLAGS is initialized with space
Rodolfo Lima wrote:
Hi, I've being trying cmake 2.5 from CVS and I've come with some
unwanted semicolons in compiler flags. Tracing this down, I've found
that CMAKE_CXX_FLAGS (and CMAKE_C_FLAGS, etc...) is initialized with a
space, so that
CMakeLists.txt:
message(X ${CMAKE_CXX_FLAGS} X)
outputs:
X X
instead of:
XX
as I'd expect, since it's empty when cmake is started. Is this the
intended behavior?
Do you have environment variables CFLAGS and CXXFLAGS set to have just a
space? Also, what OS/compiler are you using?
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] [cmake 2.5 CVS] CMAKE_${LANG}_FLAGS is initialized with space
Hi, I've being trying cmake 2.5 from CVS and I've come with some
unwanted semicolons in compiler flags. Tracing this down, I've found
that CMAKE_CXX_FLAGS (and CMAKE_C_FLAGS, etc...) is initialized with a
space, so that
CMakeLists.txt:
message(X ${CMAKE_CXX_FLAGS} X)
outputs:
X X
instead of:
XX
as I'd expect, since it's empty when cmake is started. Is this the
intended behavior?
Regards,
Rodolfo Lima.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Parallel builds do not work correctly when using "cmake -E copy" to copy files
Alan W. Irwin wrote: > So the rule seems to be that parallel builds do not work if there are two > or more separate custom targets that file depend directly or indirectly > (via > some custom command file dependency chain) on the same output files. > > Another way of summarizing these results is that file depends must be > minimized and/or custom target depends maximized in order for parallel > builds to work properly. This is correct. > My guess is I should be able to work around this CMake issue by appropriate > changes to the PLplot build system although I have a number of these > parallel build issues and the copy problem was only the most obvious. > > I do regard this as a CMake issue. Normally, the shoe is on the other > foot, > and the build system developer is desperately trying to make sure that all > the CMake file depends are obviously in place locally rather than depending > on a long easily-broken chain of dependencies to do it for them in a > minimalist way. So the big question is whether CMake can be modified so > that minimalist file depends and/or maximal (and unintuitive) target > depends > are not required in order for parallel builds to work properly. I don't see how CMake can automatically fix this. If two targets think they know how to build the same file how is CMake supposed to know which one is the correct target to build first? Consider this: 1.) Split your example into two separate directories 2.) Put the first-level custom commands in a target in one dir 3.) Put the second-level custom commands in a target in the other dir 4.) Try to build Without explicit dependence between the two targets there is no way the target in the second directory can know it must wait for the target in the first directory to build. It doesn't even know about the first-level custom command rules or that the input to one if its second-level custom commands is a generated file. The second directory's target will try to build and complain that input files are missing. This problem arises because CMake does not track file-level dependencies globally. It actually can't because some target build environments like the VS and Xcode IDEs do not provide this capability. File-level dependencies must be divided into targets. In your case the target-level dependency that must be added is a logical high-level statement of dependence: "I need all the 'tcl_examples' to be ready before I use them for anything" -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Parallel builds do not work correctly when using "cmake -E copy" to copy files
On 2007-12-13 17:07-0500 Brad King wrote:
Alan W. Irwin wrote:
So just keeping narrowly focussed on that fragment there is only one "ALL"
custom target and ADD_DEPENDENCIES would not help since it only works on
targets. Thus, I doubt there is anything locally wrong with dependencies
there. It is possible some other dependency is making a dependency pattern
that triggers the bug, but I should know more about that when I have a
simpler example that triggers the bug (or not).
I was able to reproduce the problem with the code below. It is fixed by
uncommenting the ADD_DEPENDENCIES line. You must be putting those
output files into another target that does not depend on the
tcl_examples target. Perhaps the make_documentation target?
-Brad
PROJECT(FOO)
FOREACH(f f1 f2 f3 f4 f5 f6 f7 f8 f9)
LIST(APPEND DEPS ${FOO_BINARY_DIR}/${f})
ADD_CUSTOM_COMMAND(OUTPUT ${FOO_BINARY_DIR}/${f}
COMMAND echo ${f} > ${FOO_BINARY_DIR}/${f}
)
ENDFOREACH(f)
ADD_CUSTOM_TARGET(examples ALL DEPENDS ${DEPS})
ADD_CUSTOM_TARGET(examples2 ALL DEPENDS ${DEPS})
#ADD_DEPENDENCIES(examples2 examples)
Good example, Brad!
Working from the PLplot case, I came up with another simple test case
(complete tarball attached including the required small files to be copied
for those who want to play with it).
In the PLplot case (and also the attached simple test case) there is
an additional custom command that file depends on the copied files. In
addition there is a custom target that depends on the additional custom
command output file, and a custom target that depends on the copied files.
So the rule seems to be that parallel builds do not work if there are two
or more separate custom targets that file depend directly or indirectly (via
some custom command file dependency chain) on the same output files.
Another way of summarizing these results is that file depends must be
minimized and/or custom target depends maximized in order for parallel
builds to work properly.
My guess is I should be able to work around this CMake issue by appropriate
changes to the PLplot build system although I have a number of these
parallel build issues and the copy problem was only the most obvious.
I do regard this as a CMake issue. Normally, the shoe is on the other foot,
and the build system developer is desperately trying to make sure that all
the CMake file depends are obviously in place locally rather than depending
on a long easily-broken chain of dependencies to do it for them in a
minimalist way. So the big question is whether CMake can be modified so
that minimalist file depends and/or maximal (and unintuitive) target depends
are not required in order for parallel builds to work properly.
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
__
test_parallel.tar.gz
Description: complete CMake test case for bad parallel builds
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake and WinForms
I have been experimenting with cmake for some time now and finally have it generating project files for all of my libraries, dlls, and executables except for one. The lone hold out is a C++/CLI WinForms app. Before I spend too much time on it, does anyone know if it's even possible? Thanks, Jason Stewart ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding static libraries
Well, as far as I know you can take the .a-file with linking to the full path... I don't know why CMake doesn't keep the parameters I give them? Probably if I add the libraries to the linking variables, it would take them, but that's not the point :S... If I pass CMake a full static path, I expect CMake to keep it like that. For example: If I had: /home/user/libwx.a /home/user/libwx.so I could easily link to the static one by supplying: -l/home/user/libwx.a, and it would take the static one, not the dynamic. That's how I always worked before. So it really is possible to link statically even with same name dynamic libraries in the directory... I just don't know why CMake doesn't keep it the way I tell the program to. On 12/13/07, James Bigler <[EMAIL PROTECTED]> wrote: > The mac linker is unique in how it searches for libraries. The > linker will *always* pick the shared library over the static one if > it finds a shared one first or at the same time. Also the order it > searches the library path list is different than on other *nix systems. > > By default the linker searches the paths in a depth first search. > Take the following example: > > /usr/lib/libmylib.so > /home/user/libmylib.so > > -L/home/user -lmylib > > This will pick /home/user/libmylib.so > > Now if you had this: > > /usr/lib/libmylib.so > /home/user/libmylib.a > > -L/home/user -lmylib > > This will pick up /usr/lib/libmylib.so, not /home/user/libmylib.a. > > This is because the linker looks through all the paths for a .so, > then it looks through all the paths for a .a. > > You can fix this by adding a flag: -search_paths_first > > Doing a man on ld produces this: > > -search_paths_first >By default when the -dynamic flag is in effect, > the -lx and >-weak-lx options first search for a file of > the form >`libx.dylib' in each directory in the library search > path, then >a file of the form `libx.a' is searched for in > the library >search paths. This option changes it so that in > each path >`libx.dylib' is searched for then `libx.a' before the > next path >in the library search path is searched. > > I mentioned this on the mailing list a while back, and I was told > that this flag was going to be added by default. I don't know if > that ever happened or what version it made it in. > > Also, note that if you have a .a and .dylib in the same path it will > always pick the .dylib file. No magic flags for that, I'm afraid. > > James > > On Dec 13, 2007, at 1:58 PM, Steven Van Ingelgem wrote: > > > Hi, > > > > > > I was talking to Miguel about the recent FindwxWidgets changes because > > they didn't work out on for static libraries on a Mac. > > > > Summarizing the issue is that CMake makes the (wrong) assumption that > > what you want to add are shared libraries (at least on a Mac). > > > > Let me explain in more detail what happens: > > > > The outcome of the Find-file is: > > wxWidgets_LIBRARIES: -arch ppc;-arch i386;;-framework > > QuickTime;-framework IOKit;-framework Carbon;-framework > > Cocoa;-framework > > System;;/usr/lib/libwx_macu_adv-2.9.a;/usr/lib/ > > libwx_macu_core-2.9.a;/usr/lib/libwx_base_carbonu_net-2.9.a;/usr/ > > lib/libwx_base_carbonu-2.9.a;/usr/lib/libwx_base_carbonu_xml-2.9.a;- > > framework > > WebKit;-lwxregexu-2.9;-lwxexpat-2.9;-lwxtiff-2.9;-lwxjpeg-2.9;- > > lwxpng-2.9;-lwxzlib-2.9;-lpthread;-liconv > > > > As you might notice it's a mix of static and dynamic libraries. > > > > Then I add them with the command > > TARGET_LINK_LIBRARIES(...) > > > > > > Then when I want to link them on a Linux it adds -Wl,-Bstatic -l... > > where ... is the NAME of the library, not the path that was passed in. > > Example: -Wl,-Bstatic -lwx_macu_core-2.9 - > > lwx_base_carbonu_net-2.9 ... etc ... > > > > Now on a Mac (XCode 2.5, GCC 4.0.1) this -Wl flag doesn't exist, but > > the library list STILL includes "-lwx_macu_core-2.9 > > -lwx_base_carbonu_net-2.9", so the directory where it needs to look > > for the static libraries is lost. > > > > > > My proposal is to change the behaviour of CMake to add the static > > libraries as they are given on the command line... The user knows > > best! For example if I would have a static library in > > /home/steven/test/libtest.a, and one in /usr/lib/libtest.a with BOTH > > the same name, and BOTH static, but I add the > > /home/steven/test/libtest.a, then CMake will end up using the > > /usr/lib/libtest.a... Even though I said to use the one in "home". > > > > > > I hope I made myself completely clear here... And I hope I'm not going > > completely nuts here or is this really a bug in CMake? > > > > > > Steven, out. > > ___ > > CMake mailing list > > CMake@cmake.org > > http://www.cmake.org/mailman/listinfo/cmake > > ___ CMake mailing list CMake@cmake.or
Re: [CMake] Parallel builds do not work correctly when using "cmake -E copy" to copy files
Alan W. Irwin wrote:
> So just keeping narrowly focussed on that fragment there is only one "ALL"
> custom target and ADD_DEPENDENCIES would not help since it only works on
> targets. Thus, I doubt there is anything locally wrong with dependencies
> there. It is possible some other dependency is making a dependency pattern
> that triggers the bug, but I should know more about that when I have a
> simpler example that triggers the bug (or not).
I was able to reproduce the problem with the code below. It is fixed by
uncommenting the ADD_DEPENDENCIES line. You must be putting those
output files into another target that does not depend on the
tcl_examples target. Perhaps the make_documentation target?
-Brad
PROJECT(FOO)
FOREACH(f f1 f2 f3 f4 f5 f6 f7 f8 f9)
LIST(APPEND DEPS ${FOO_BINARY_DIR}/${f})
ADD_CUSTOM_COMMAND(OUTPUT ${FOO_BINARY_DIR}/${f}
COMMAND echo ${f} > ${FOO_BINARY_DIR}/${f}
)
ENDFOREACH(f)
ADD_CUSTOM_TARGET(examples ALL DEPENDS ${DEPS})
ADD_CUSTOM_TARGET(examples2 ALL DEPENDS ${DEPS})
#ADD_DEPENDENCIES(examples2 examples)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Parallel builds do not work correctly when using "cmake -E copy" to copy files
Alan W. Irwin wrote: > It was good to hear that make -j N normally works with CMake. Yes indeed. I frequently run make -j70 across a 35-host dual-CPU cluster using distcc, and every time I've updated CMake's files, it's correctly rebuilt the makefiles before continuing. http://www.cmake.org/mailman/listinfo/cmake
[CMake] question about "no debugging symbols found"
Hello every expert: I have one c++ code (.cxx file) with a CMakeLists.txt file, this program need ITK, I have already setup everything ready in my linux machine. I have built a binary file by following steps: 1) ccmake ., setup the ITK path, configuration and generation 2) make Now I want to debug this code, I want to use emacs+gdb. But during the process, it says "no debugging symbols found", I do not know where to swich on the debug? I cannot find the switch in MakeFile. Does anyone could help me out, I really appreciate it! Ping _ 天凉了，添衣了，心动了，“七件”了 http://get.live.cn___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking unit tests
2007/12/12, Marcus <[EMAIL PROTECTED]>: > In the past (when I was using SCons) I compiled the source files into > object files, and then linked the same object files into both the test > executable and the shared library. Is it possible to do this with CMake? As far as I know there's no official support in cmake for this. But I had the same problem not long ago and here is how I've done it: http://trac.licq.org/browser/branches/newapi/licq/src/CMakeLists.txt Hope that helps. // Erik -- Erik Johansson Home Page: http://ejohansson.se/ PGP Key: http://ejohansson.se/erik.asc ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Parallel builds do not work correctly when using "cmake -E copy" to copy files
On 2007-12-13 15:39-0500 Bill Hoffman wrote: Alan W. Irwin wrote: My obvious next step is to try and make a simple CMake example that reliably reproduces the bug, but this is such an important bug (at least for those with access to multiprocessors who want to use parallel builds) that I thought the above result was worth reporting immediately since it tends to point the finger at something CMake is doing rather than some bug in GNU make. We use -j N builds all the time at Kitware for VTK, ParaView and CMake. It is however, possible to create input to CMake that will not work in a parallel environment. A simple example would be the best way to figure out if there is a way around the issue you are having. One thing you might want to look at is the add_dependancy command, and make sure that your custom targets are built in some order. From your email, I am not exactly sure what targets are involved and what files are created at what time. It was good to hear that make -j N normally works with CMake. To answer your question, from the CMake language fragment in the first e-mail on this issue, there is a custom command (with OUTPUT signature with full pathname) for each file to be copied, and then an overall "ALL" custom target that file depends (with full pathname) on those OUTPUT files. So just keeping narrowly focussed on that fragment there is only one "ALL" custom target and ADD_DEPENDENCIES would not help since it only works on targets. Thus, I doubt there is anything locally wrong with dependencies there. It is possible some other dependency is making a dependency pattern that triggers the bug, but I should know more about that when I have a simpler example that triggers the bug (or not). 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] Adding static libraries
The mac linker is unique in how it searches for libraries. The linker will *always* pick the shared library over the static one if it finds a shared one first or at the same time. Also the order it searches the library path list is different than on other *nix systems. By default the linker searches the paths in a depth first search. Take the following example: /usr/lib/libmylib.so /home/user/libmylib.so -L/home/user -lmylib This will pick /home/user/libmylib.so Now if you had this: /usr/lib/libmylib.so /home/user/libmylib.a -L/home/user -lmylib This will pick up /usr/lib/libmylib.so, not /home/user/libmylib.a. This is because the linker looks through all the paths for a .so, then it looks through all the paths for a .a. You can fix this by adding a flag: -search_paths_first Doing a man on ld produces this: -search_paths_first By default when the -dynamic flag is in effect, the -lx and -weak-lx options first search for a file of the form `libx.dylib' in each directory in the library search path, then a file of the form `libx.a' is searched for in the library search paths. This option changes it so that in each path `libx.dylib' is searched for then `libx.a' before the next path in the library search path is searched. I mentioned this on the mailing list a while back, and I was told that this flag was going to be added by default. I don't know if that ever happened or what version it made it in. Also, note that if you have a .a and .dylib in the same path it will always pick the .dylib file. No magic flags for that, I'm afraid. James On Dec 13, 2007, at 1:58 PM, Steven Van Ingelgem wrote: Hi, I was talking to Miguel about the recent FindwxWidgets changes because they didn't work out on for static libraries on a Mac. Summarizing the issue is that CMake makes the (wrong) assumption that what you want to add are shared libraries (at least on a Mac). Let me explain in more detail what happens: The outcome of the Find-file is: wxWidgets_LIBRARIES: -arch ppc;-arch i386;;-framework QuickTime;-framework IOKit;-framework Carbon;-framework Cocoa;-framework System;;/usr/lib/libwx_macu_adv-2.9.a;/usr/lib/ libwx_macu_core-2.9.a;/usr/lib/libwx_base_carbonu_net-2.9.a;/usr/ lib/libwx_base_carbonu-2.9.a;/usr/lib/libwx_base_carbonu_xml-2.9.a;- framework WebKit;-lwxregexu-2.9;-lwxexpat-2.9;-lwxtiff-2.9;-lwxjpeg-2.9;- lwxpng-2.9;-lwxzlib-2.9;-lpthread;-liconv As you might notice it's a mix of static and dynamic libraries. Then I add them with the command TARGET_LINK_LIBRARIES(...) Then when I want to link them on a Linux it adds -Wl,-Bstatic -l... where ... is the NAME of the library, not the path that was passed in. Example: -Wl,-Bstatic -lwx_macu_core-2.9 - lwx_base_carbonu_net-2.9 ... etc ... Now on a Mac (XCode 2.5, GCC 4.0.1) this -Wl flag doesn't exist, but the library list STILL includes "-lwx_macu_core-2.9 -lwx_base_carbonu_net-2.9", so the directory where it needs to look for the static libraries is lost. My proposal is to change the behaviour of CMake to add the static libraries as they are given on the command line... The user knows best! For example if I would have a static library in /home/steven/test/libtest.a, and one in /usr/lib/libtest.a with BOTH the same name, and BOTH static, but I add the /home/steven/test/libtest.a, then CMake will end up using the /usr/lib/libtest.a... Even though I said to use the one in "home". I hope I made myself completely clear here... And I hope I'm not going completely nuts here or is this really a bug in CMake? Steven, out. ___ 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] libxml2
Hi Pau Garcia i Quiles,
Thanks for the suggestion. It works well on linux and Windows.
However, it is still not happy with MinGW. To compile with MinGW, we
need to have
TARGET_LINK_LIBRARIES( my_lib ITKCommon ITKIO libxml2)
and set ${LIBXML2_LIBRARIES} in CMake GUI to the directory where
libxml2.{lib,a,dll} can be found.
Instead, if we change the line to
TARGET_LINK_LIBRARIES( my_lib ITKCommon ITKIO ${LIBXML2_LIBRARIES} )
the errors we get are something like
C:\Isaac\Fars_Isaac\source_svn\bin\maciej_seg\libmaciejseg.a(xml_util.obj)(.text+0x3776):xml_util.cpp:
undefined reference to `_imp__xmlFree'
Any suggestions?
Charlene
On Dec 11, 2007 2:40 AM, Pau Garcia i Quiles <[EMAIL PROTECTED]> wrote:
>
> 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
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Adding static libraries
Hi, I was talking to Miguel about the recent FindwxWidgets changes because they didn't work out on for static libraries on a Mac. Summarizing the issue is that CMake makes the (wrong) assumption that what you want to add are shared libraries (at least on a Mac). Let me explain in more detail what happens: The outcome of the Find-file is: wxWidgets_LIBRARIES: -arch ppc;-arch i386;;-framework QuickTime;-framework IOKit;-framework Carbon;-framework Cocoa;-framework System;;/usr/lib/libwx_macu_adv-2.9.a;/usr/lib/libwx_macu_core-2.9.a;/usr/lib/libwx_base_carbonu_net-2.9.a;/usr/lib/libwx_base_carbonu-2.9.a;/usr/lib/libwx_base_carbonu_xml-2.9.a;-framework WebKit;-lwxregexu-2.9;-lwxexpat-2.9;-lwxtiff-2.9;-lwxjpeg-2.9;-lwxpng-2.9;-lwxzlib-2.9;-lpthread;-liconv As you might notice it's a mix of static and dynamic libraries. Then I add them with the command TARGET_LINK_LIBRARIES(...) Then when I want to link them on a Linux it adds -Wl,-Bstatic -l... where ... is the NAME of the library, not the path that was passed in. Example: -Wl,-Bstatic -lwx_macu_core-2.9 -lwx_base_carbonu_net-2.9 ... etc ... Now on a Mac (XCode 2.5, GCC 4.0.1) this -Wl flag doesn't exist, but the library list STILL includes "-lwx_macu_core-2.9 -lwx_base_carbonu_net-2.9", so the directory where it needs to look for the static libraries is lost. My proposal is to change the behaviour of CMake to add the static libraries as they are given on the command line... The user knows best! For example if I would have a static library in /home/steven/test/libtest.a, and one in /usr/lib/libtest.a with BOTH the same name, and BOTH static, but I add the /home/steven/test/libtest.a, then CMake will end up using the /usr/lib/libtest.a... Even though I said to use the one in "home". I hope I made myself completely clear here... And I hope I'm not going completely nuts here or is this really a bug in CMake? Steven, out. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake CVS errors
Here is another one: 531:[EMAIL PROTECTED]:Build]$ bin/cmake --help-module-list cmake version 2.5-20071213 Internal error: Modules list is empty. 532:[EMAIL PROTECTED]:Build]$ bin/cmake --version cmake version 2.5-20071213 -- Mike Jackson Senior Research Engineer Innovative Management & Technology Services On Dec 13, 2007, at 3:39 PM, Bill Hoffman wrote: Mike Jackson wrote: doh.. cmake 2.4.7 was on my path. I should have done: bin/cmake --help-variable-list /tmp/variable.html sorry for the noise Actually, you did find a bug, and I have fixed the docs with the wrong case for the v. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake CVS errors
Mike Jackson wrote: doh.. cmake 2.4.7 was on my path. I should have done: bin/cmake --help-variable-list /tmp/variable.html sorry for the noise Actually, you did find a bug, and I have fixed the docs with the wrong case for the v. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Parallel builds do not work correctly when using "cmake -E copy" to copy files
Alan W. Irwin wrote: My obvious next step is to try and make a simple CMake example that reliably reproduces the bug, but this is such an important bug (at least for those with access to multiprocessors who want to use parallel builds) that I thought the above result was worth reporting immediately since it tends to point the finger at something CMake is doing rather than some bug in GNU make. We use -j N builds all the time at Kitware for VTK, ParaView and CMake. It is however, possible to create input to CMake that will not work in a parallel environment. A simple example would be the best way to figure out if there is a way around the issue you are having. One thing you might want to look at is the add_dependancy command, and make sure that your custom targets are built in some order. From your email, I am not exactly sure what targets are involved and what files are created at what time. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake CVS errors
doh.. cmake 2.4.7 was on my path. I should have done: bin/cmake --help-variable-list /tmp/variable.html sorry for the noise -- Mike Jackson Senior Research Engineer Innovative Management & Technology Services On Dec 13, 2007, at 3:09 PM, Bill Hoffman wrote: Mike Jackson wrote: Not sure if this is know but using today's cvs I tried the following: 504:[EMAIL PROTECTED]:bin]$ cmake --help-Variable-list /tmp/out.txt CMake Error: The source directory "/tmp/out.txt" does not exist. Specify --help for usage, or press the help button on the CMake GUI. Bug? Also, there is a slight inconsistency in the naming of the 'variable' argument: --help-variable var [file] = Print help for a single variable and exit. --help-Variable-list [file] = List documented variables and exit. --help-variables [file] = Print help for all variables and exit. Note the capital 'V' in the second line. There is a bug in that help, the lowercase V works fine, so --help- variable-list. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Parallel builds do not work correctly when using "cmake -E copy" to copy files
On 2007-12-12 17:10-0800 Alan W. Irwin wrote: A set of custom rules to copy files from the source tree to the build tree is screwing up for parallel builds on Debian testing with cmake 2.4.7. Here is part of the "make -j 2" output: make -f examples/tcl/CMakeFiles/tclIndex_examples_tcl.dir/build.make examples/tcl/CMakeFiles/tclIndex_examples_tcl.dir/build [...] make[2]: *** [examples/tcl/x05] Error 1 make[2]: Leaving directory `/home/software/plplot_cvs/HEAD/build_dir' /usr/bin/cmake -E cmake_progress_report /home/software/plplot_cvs/HEAD/build_dir/CMakeFiles make[1]: *** [examples/tcl/CMakeFiles/tclIndex_examples_tcl.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs Note, the above make command is generated recursively from the overall "make -j 2" command. I have no idea how the -j option was propagated in that case, but I assume it was via some Makefile variable. Now here is the really strange part. If I directly run make -f examples/tcl/CMakeFiles/tclIndex_examples_tcl.dir/build.make \ examples/tcl/CMakeFiles/tclIndex_examples_tcl.dir/clean make -j 2 -f examples/tcl/CMakeFiles/tclIndex_examples_tcl.dir/build.make \ examples/tcl/CMakeFiles/tclIndex_examples_tcl.dir/build from the command line there are no extra copying operations and no errors. Also, all other attempts to reproduce this bug from a hand-crafted Makefile have failed. However, the double copy is reliably reproduced in the build tree by make clean make -j 2 and intermittently that above sequence produces other "*** Waiting for unfinished jobs..." errors as well, but those are more complicated than the simple double copy errors I have documented so I won't go into details. In sum, so far it appears I need CMake-generated Makefiles that are recursively run with "make -j 2" in order to see parallel build errors. Thus, my working hypothesis is these bad parallel build results are due to some CMake error (a Makefile variable that is set or propagated incorrectly?) in the way it does make recursion. My obvious next step is to try and make a simple CMake example that reliably reproduces the bug, but this is such an important bug (at least for those with access to multiprocessors who want to use parallel builds) that I thought the above result was worth reporting immediately since it tends to point the finger at something CMake is doing rather than some bug in GNU make. 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] cmake CVS errors
Mike Jackson wrote: Not sure if this is know but using today's cvs I tried the following: 504:[EMAIL PROTECTED]:bin]$ cmake --help-Variable-list /tmp/out.txt CMake Error: The source directory "/tmp/out.txt" does not exist. Specify --help for usage, or press the help button on the CMake GUI. Bug? Also, there is a slight inconsistency in the naming of the 'variable' argument: --help-variable var [file] = Print help for a single variable and exit. --help-Variable-list [file] = List documented variables and exit. --help-variables [file] = Print help for all variables and exit. Note the capital 'V' in the second line. There is a bug in that help, the lowercase V works fine, so --help-variable-list. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake CVS errors
Mike Jackson wrote: > Not sure if this is know but using today's cvs I tried the following: > > 504:[EMAIL PROTECTED]:bin]$ cmake --help-Variable-list /tmp/out.txt > CMake Error: The source directory "/tmp/out.txt" does not exist. > Specify --help for usage, or press the help button on the CMake GUI. > > Bug? I think the right command is cmake --help-variable-list /tmp/out.txt -- Filipe Sousa signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake CVS errors
Not sure if this is know but using today's cvs I tried the following: 504:[EMAIL PROTECTED]:bin]$ cmake --help-Variable-list /tmp/out.txt CMake Error: The source directory "/tmp/out.txt" does not exist. Specify --help for usage, or press the help button on the CMake GUI. Bug? Also, there is a slight inconsistency in the naming of the 'variable' argument: --help-variable var [file] = Print help for a single variable and exit. --help-Variable-list [file] = List documented variables and exit. --help-variables [file] = Print help for all variables and exit. Note the capital 'V' in the second line. I was going to update my QtAssistant generator shell script with the new options.. -- Mike Jackson imikejackson & gmail * com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] PRE_BUILD custom commands don't appear to be working....
I'm trying to add a prebuild custom command to a NMake target, but it
doesn't appear to be running in the right place.
Here's an example:
CMakelists.txt:
Project(Hello)
add_library (Hello hello.cxx hello.h)
add_custom_command(TARGET Hello PRE_BUILD
COMMAND ${CMAKE_COMMAND}
ARGS -P ${PROJECT_SOURCE_DIR}/Hello.cmake
)
Hello.cmake
MESSAGE("Hello.cmake ran")
So, I would hope that the Hello.cmake file would get run first, but it
appears to be run as if it is a POST_BUILD.
$ cmake.exe -G "NMake Makefiles" .
... stuff ..
$ nmake
Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
[100%] Building CXX object CMakeFiles/Hello.dir/hello.obj
hello.cxx
Linking CXX static library Hello.lib
Prebuild rule ran
[100%] Built target Hello
[EMAIL PROTECTED] /c/Devel/SVN/trunk/build/test/qq/Hello
Doesn't PRE_BUILD request that that command gets run before the
hello.cxx file gets compiled?
Joe
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindBoost bug on debian or something's missing?
the below line should be something like:
TARGET_LINK_LIBRARIES ( time ${Boost_Date_Time_Library} )
Look at the FindBoost.cmake file for the exact name of the library
variable. The way you had the line you would be including a directory
and not the actual boost date_time library.
--
Mike Jackson Senior Research Engineer
Innovative Management & Technology Services
On Dec 13, 2007, at 1:13 PM, Tomasz Kalkosiński wrote:
TARGET_LINK_LIBRARIES (time ${Boost_LIBRARY_DIRS})
MESSAGE ("Library directories for Boost: " ${Boost_LIBRARY_DIRS})
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindBoost bug on debian or something's missing? - errata
Did you build the "Data_Time" boost library? Are you linking against
the libboost_date_time library? Run a 'make VERBOSE=1' and post
the ouput.
--
Mike Jackson Senior Research Engineer
Innovative Management & Technology Services
On Dec 13, 2007, at 1:19 PM, Tomasz Kalkosiński wrote:
Sorry, I forgot to add make output:
make
Scanning dependencies of target time
[100%] Building CXX object CMakeFiles/time.dir/time.o
Linking CXX executable time
CMakeFiles/time.dir/time.o: In function
`boost::date_time::month_formatterboost::date_time::simple_format, char>::format_month
(boost::gregorian::greg_month const&, std::basic_ostreamstd::char_traits >&)':
time.cpp:
(.text._ZN5boost9date_time15month_formatterINS_9gregorian10greg_monthE
NS0_13simple_formatIcEEcE12format_monthERKS3_RSo
[boost::date_time::month_formatterboost::date_time::simple_format, char>::format_month
(boost::gregorian::greg_month const&, std::basic_ostreamstd::char_traits >&)]+0x2d): undefined reference to
`boost::gregorian::greg_month::as_short_string() const'
time.cpp:
(.text._ZN5boost9date_time15month_formatterINS_9gregorian10greg_monthE
NS0_13simple_formatIcEEcE12format_monthERKS3_RSo
[boost::date_time::month_formatterboost::date_time::simple_format, char>::format_month
(boost::gregorian::greg_month const&, std::basic_ostreamstd::char_traits >&)]+0x4c): undefined reference to
`boost::gregorian::greg_month::as_long_string() const'
collect2: ld returned 1 exit status
make[2]: *** [time] Error 1
make[1]: *** [CMakeFiles/time.dir/all] Error 2
make: *** [all] Error 2
Source for time.cpp:
$ cat time.cpp
#include "boost/date_time/posix_time/posix_time.hpp"
#include
int
main()
{
using namespace boost::posix_time;
using namespace boost::gregorian;
ptime now = microsec_clock::local_time();
time_iterator titr(now, milliseconds(800));
for (int i = 0 ; i < 10 ; ++titr, ++i)
{
ptime later = now + milliseconds (800);
std::cout << to_simple_string(*titr) << std::endl;
std::cout << to_simple_string(now) << std::endl;
std::cout << to_simple_string(later) << std::endl;
do {
now = microsec_clock::local_time();
} while (now < later);
}
return 0;
}
Greetings,
Tomasz Kalkosiński
___
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] FindBoost bug on debian or something's missing? - errata
Sorry, I forgot to add make output:
> make
Scanning dependencies of target time
[100%] Building CXX object CMakeFiles/time.dir/time.o
Linking CXX executable time
CMakeFiles/time.dir/time.o: In function
`boost::date_time::month_formatter,
char>::format_month(boost::gregorian::greg_month const&,
std::basic_ostream >&)':
time.cpp:(.text._ZN5boost9date_time15month_formatterINS_9gregorian10greg_monthENS0_13simple_formatIcEEcE12format_monthERKS3_RSo[boost::date_time::month_formatter,
char>::format_month(boost::gregorian::greg_month const&,
std::basic_ostream >&)]+0x2d): undefined reference
to `boost::gregorian::greg_month::as_short_string() const'
time.cpp:(.text._ZN5boost9date_time15month_formatterINS_9gregorian10greg_monthENS0_13simple_formatIcEEcE12format_monthERKS3_RSo[boost::date_time::month_formatter,
char>::format_month(boost::gregorian::greg_month const&,
std::basic_ostream >&)]+0x4c): undefined reference
to `boost::gregorian::greg_month::as_long_string() const'
collect2: ld returned 1 exit status
make[2]: *** [time] Error 1
make[1]: *** [CMakeFiles/time.dir/all] Error 2
make: *** [all] Error 2
Source for time.cpp:
$ cat time.cpp
#include "boost/date_time/posix_time/posix_time.hpp"
#include
int
main()
{
using namespace boost::posix_time;
using namespace boost::gregorian;
ptime now = microsec_clock::local_time();
time_iterator titr(now, milliseconds(800));
for (int i = 0 ; i < 10 ; ++titr, ++i)
{
ptime later = now + milliseconds (800);
std::cout << to_simple_string(*titr) << std::endl;
std::cout << to_simple_string(now) << std::endl;
std::cout << to_simple_string(later) << std::endl;
do {
now = microsec_clock::local_time();
} while (now < later);
}
return 0;
}
Greetings,
Tomasz Kalkosiński
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What's happening to CMake ??? Please help !!!
Cem DEMiRKIR wrote: No, David, it still continues producing the same error as before. I've changed the Bin directory to D:\Test and it still produces the error. Run cmake from the command line with --debug-trycompile. Then go into CMakeTmp and look at the project that is created, and try to build it and see why the files are not being created. One odd thing, is this: "Z:\Libraries\Insight\bin/CMakeTmp/cmTryCompileExec.exe I would think that it should be looking in CMakeFiles/CMakeTmp. Can you give the exact commands you are running? Also, a very good thing to try would be a very simple cmake project. Create a CMakeLists.txt file with this: add_library(foo foo.c) Also create an empty foo.c file. Then run cmake on that. Does it work? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] FindBoost bug on debian or something's missing?
Hey
I have very strange problem using cmake (cmake version 2.4-patch 7, from
packages) on debian. I have small progam : time.cpp. It uses boost_date_time
library. It compiles fine with g++ time.cpp -lboost_date_time.
So I try to write CMakeLists.txt for that:
$ cat CMakeLists.txt
SET (TIME_SRCS time.cpp)
ADD_EXECUTABLE (time ${TIME_SRCS})
FIND_PACKAGE (Boost REQUIRED)
INCLUDE_DIRECTORIES (${Boost_INCLUDE_DIRS})
MESSAGE ("Include directories for Boost: " ${Boost_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES (time ${Boost_LIBRARY_DIRS})
MESSAGE ("Library directories for Boost: " ${Boost_LIBRARY_DIRS})
Output from cmake is:
cmake .
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Check size of void*
-- Check size of void* - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
Include directories for Boost: /usr/include
Library directories for Boost: /usr/lib
-- Configuring done
Warning: Ignoring path found in link libraries for target: time, path is:
/usr/lib. Expected a library name or a full path to a library name.
-- Generating done
Something is obviously wrong. I don't have problems with other FindXXX macros,
only Boost seems to be broken or my CMakeLists.txt miss something. What do you
think?
Greetings,
Tomasz Kalkosiński
Boost location:
$ ls /usr/lib/libboost_date_time*
/usr/lib/libboost_date_time.a@
/usr/lib/libboost_date_time-gcc41-mt-1_34_1.so@
/usr/lib/libboost_date_time-gcc41-1_34_1.a
/usr/lib/libboost_date_time-gcc41-mt-1_34_1.so.1.34.1
/usr/lib/libboost_date_time-gcc41-1_34_1.so@
/usr/lib/libboost_date_time-mt.a@
/usr/lib/libboost_date_time-gcc41-1_34_1.so.1.34.1
/usr/lib/libboost_date_time-mt.so@
/usr/lib/libboost_date_time-gcc41-mt-1_34_1.a
/usr/lib/libboost_date_time.so@
$ ls /usr/include/boost/date_time*
/usr/include/boost/date_time.hpp
/usr/include/boost/date_time:
[...]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] What's happening to CMake ??? Please help !!!
Hi, David And also tested it for "C:" and it doesn't work either. Regards Cem _ From: David Cole [mailto:[EMAIL PROTECTED] Sent: Thursday, December 13, 2007 6:50 PM To: Cem DEMiRKIR Cc: CMake Mailing List Subject: Re: [CMake] What's happening to CMake ??? Please help !!! Are your source and binary directories on different drive letters? Does the problem occur if you use "C:" instead of "Z:" for the binary tree? On 12/12/07, Cem DEMiRKIR <[EMAIL PROTECTED]> wrote: Hi David, Unfortunately it doesn't work. It produces the same errors. Regards Cem DEMiRKIR _ From: David Cole [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 9:34 PM To: Cem DEMiRKIR Cc: CMake Mailing List Subject: Re: [CMake] What's happening to CMake ??? Please help !!! CMake 2.4.4 had some serious flaws and was only available for a very short time before being fixed by 2.4.5 Update to the latest CMake release (2.4.7) and try again. And don't forget to start over with an empty binary directory after updating CMake... HTH, David On 12/11/07, Cem DEMiRKIR <[EMAIL PROTECTED]> wrote: Hello CMake users & developers, I've been trying to build ITK on my machine, and obviously is not related to what is built, and CMake produces some errors at the configuration step. Perhaps someoneelse has already encountered similar type of problem ? My setup: Windows XP, ITK 3.4.0 Latest Release, CMake 2.4.4, Visual Studio .NET 2005 w/ Visual C++ 8 At first I've observed the following CMake Errror message box and then a lot of errors coming up when I choose OK. CMake Error: Unable to find executable for TRY_RUN: tried "Z:\Libraries\Insight\bin/CMakeTmp/cmTryCompileExec.exe" and "Z:\Libraries\Insight\bin/CMakeTmp/Debug/cmTryCompileExec.exe" and "Z:\Libraries\Insight\bin/CMakeTmp/Development/cmTryCompileExec.exe". [CMake is correct; these files do not exist, but the log indicates no error for the building of these executables.] I've compiled previous version of ITK, or VTK, etc. without any problem before, but after deleting old one and trying to build the latest release, I've got these errors. I'd be grateful to anyone who help me resolve this problem ? Sincerely Cem DEMiRKIR ___ 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] What's happening to CMake ??? Please help !!!
No, David, it still continues producing the same error as before. I've changed the Bin directory to D:\Test and it still produces the error. Regards Cem _ From: David Cole [mailto:[EMAIL PROTECTED] Sent: Thursday, December 13, 2007 6:50 PM To: Cem DEMiRKIR Cc: CMake Mailing List Subject: Re: [CMake] What's happening to CMake ??? Please help !!! Are your source and binary directories on different drive letters? Does the problem occur if you use "C:" instead of "Z:" for the binary tree? On 12/12/07, Cem DEMiRKIR <[EMAIL PROTECTED]> wrote: Hi David, Unfortunately it doesn't work. It produces the same errors. Regards Cem DEMiRKIR _ From: David Cole [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 9:34 PM To: Cem DEMiRKIR Cc: CMake Mailing List Subject: Re: [CMake] What's happening to CMake ??? Please help !!! CMake 2.4.4 had some serious flaws and was only available for a very short time before being fixed by 2.4.5 Update to the latest CMake release (2.4.7) and try again. And don't forget to start over with an empty binary directory after updating CMake... HTH, David On 12/11/07, Cem DEMiRKIR <[EMAIL PROTECTED]> wrote: Hello CMake users & developers, I've been trying to build ITK on my machine, and obviously is not related to what is built, and CMake produces some errors at the configuration step. Perhaps someoneelse has already encountered similar type of problem ? My setup: Windows XP, ITK 3.4.0 Latest Release, CMake 2.4.4, Visual Studio .NET 2005 w/ Visual C++ 8 At first I've observed the following CMake Errror message box and then a lot of errors coming up when I choose OK. CMake Error: Unable to find executable for TRY_RUN: tried "Z:\Libraries\Insight\bin/CMakeTmp/cmTryCompileExec.exe" and "Z:\Libraries\Insight\bin/CMakeTmp/Debug/cmTryCompileExec.exe" and "Z:\Libraries\Insight\bin/CMakeTmp/Development/cmTryCompileExec.exe". [CMake is correct; these files do not exist, but the log indicates no error for the building of these executables.] I've compiled previous version of ITK, or VTK, etc. without any problem before, but after deleting old one and trying to build the latest release, I've got these errors. I'd be grateful to anyone who help me resolve this problem ? Sincerely Cem DEMiRKIR ___ 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] What's happening to CMake ??? Please help !!!
Are your source and binary directories on different drive letters? Does the problem occur if you use "C:" instead of "Z:" for the binary tree? On 12/12/07, Cem DEMiRKIR <[EMAIL PROTECTED]> wrote: > > Hi David, > Unfortunately it doesn't work. It produces the same errors. > > Regards > Cem DEMiRKIR > > -- > *From:* David Cole [mailto:[EMAIL PROTECTED] > *Sent:* Tuesday, December 11, 2007 9:34 PM > *To:* Cem DEMiRKIR > *Cc:* CMake Mailing List > *Subject:* Re: [CMake] What's happening to CMake ??? Please help !!! > > > CMake 2.4.4 had some serious flaws and was only available for a very short > time before being fixed by 2.4.5 > > Update to the latest CMake release (2.4.7) and try again. > > > And don't forget to start over with an empty binary directory after > updating CMake... > > > > > HTH, > David > > > On 12/11/07, Cem DEMiRKIR <[EMAIL PROTECTED]> wrote: > > > > Hello CMake users & developers, > > > > I've been trying to build ITK on my machine, and obviously is not > > related to what is built, and CMake produces > > some errors at the configuration step. Perhaps someoneelse has already > > encountered > > similar type of problem ? > > > > My setup: > > Windows XP, ITK 3.4.0 Latest Release, CMake 2.4.4, Visual Studio .NET > > 2005 > > w/ Visual C++ 8 > > > > At first I've observed the following CMake Errror message box and then a > > lot of errors coming up when I choose OK. > > > > > > CMake Error: Unable to find executable for TRY_RUN: tried > > "Z:\Libraries\Insight\bin/CMakeTmp/cmTryCompileExec.exe" and > > "Z:\Libraries\Insight\bin/CMakeTmp/Debug/cmTryCompileExec.exe" and > > "Z:\Libraries\Insight\bin/CMakeTmp/Development/cmTryCompileExec.exe". > > [CMake is correct; these files do not exist, but the log indicates no > > error for the building of these executables.] > > > > I've compiled previous version of ITK, or VTK, etc. without any problem > > before, but after deleting old one and trying to build the latest release, > > I've got these errors. I'd be grateful to anyone who help me resolve this > > problem ? > > > > Sincerely > > Cem DEMiRKIR > > > > > > ___ > > 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] turning off compile testing
> -Original Message- > > We do it this way: > > > > cmake -DCMAKE_CXX_COMPILER_WORKS=1 -DCMAKE_C_COMPILER_WORKS=1 > > -DHAVE_CMAKE_SIZEOF_VOID_P=1 . > > > > That looks like a bad idea to me The void one in particular. You > should really be careful about setting stuff like this by hand > It's a hack granted, but there is no other way of telling CMake to ignore the compiler - the compiler tests aren't as clean as one might like, and so fail for some of the compilers that we use. The HAVE_CMAKE_SIZEOF_VOID_P variable is used, if I remember correctly, to determine whether the host environment is 32 or 64 bit in order to select the correct compiler. However as we are cross compiling, the host environment is entirely irrelevant, however without this variable set cmake persists in trying to work it out. I'm sure that most of this pain goes away in the 2.7 release - I'm looking forward to evaluating the new cross build stuff sometime early next year. Joe ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] turning off compile testing
Josef Karthauser wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jesse Corrington Sent: 12 December 2007 00:46 To: cmake@cmake.org Subject: [CMake] turning off compile testing Is there any way to turn off try compile during configuration? We do it this way: cmake -DCMAKE_CXX_COMPILER_WORKS=1 -DCMAKE_C_COMPILER_WORKS=1 -DHAVE_CMAKE_SIZEOF_VOID_P=1 . That looks like a bad idea to me The void one in particular. You should really be careful about setting stuff like this by hand -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Controling OutputDirectory in the vcprojs
Hi Again, FWIW here's how I managed to have mangled names in the output *and* in the right folder instead of $(OutDir). project(FOO) add_library(FOO foo.cpp) set_target_properties( FOO PROPERTIES DEBUG_OUTPUT_NAME "foo-debug" RELEASE_OUTPUT_NAME "foo-release") add_custom_command(TARGET FOO POST_BUILD COMMAND copy $(TargetPath) $(ProjectDir) ) Best -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake and testing qt library project
Hi all, I am developing a library and usign cmake as a building tool.I want to test my library when building. Directory structure is like this:: -src |_ lib_src1.cpp |_ lib_src2.cpp |_ lib_src3.cpp -test |_ test.cpp I wrote CMakeLists.txt in src folder and it is working fine. But i want to add test directory and can run test for library.test.cpp tests my librarys.How can I do this ? Thanks in advance Ramazan ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake and testing qt library project
Hi all, I am developing a library and usign cmake as a building tool.I want to test my library when building. Directory structure is like this:: -src--lib_src1.cpp ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] turning off compile testing
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jesse Corrington > Sent: 12 December 2007 00:46 > To: cmake@cmake.org > Subject: [CMake] turning off compile testing > > Is there any way to turn off try compile during configuration? We do it this way: cmake -DCMAKE_CXX_COMPILER_WORKS=1 -DCMAKE_C_COMPILER_WORKS=1 -DHAVE_CMAKE_SIZEOF_VOID_P=1 . Joe ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
