[CMake] Output of ADD_CUSTOM_COMMAND generated multiple times
Hi all,
I'm experiencing the following problem with ADD_CUSTOM_COMMAND:
The commands defined for it are executed multiple times, if multiple
targets depend on it and I run a parallel make afterwards.
An example makes this easier to understand:
PROJECT(Test)
cmake_minimum_required(VERSION 2.6)
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/a
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/a)
ADD_CUSTOM_TARGET(b
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/b
DEPENDS ${CMAKE_BINARY_DIR}/a)
ADD_CUSTOM_TARGET(c
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/c
DEPENDS ${CMAKE_BINARY_DIR}/a)
ADD_CUSTOM_TARGET(world)
ADD_DEPENDENCIES(world b)
ADD_DEPENDENCIES(world c)
When running a make -j2 world afterwards, the following output appears:
[ 0%] [ 0%] Generating a
Generating a
[ 50%] [100%] Built target b
Built target c
[100%] Built target world
When doing a make -j1 world, a is generated only once. From my
understanding a should only be generated once in the first case as well.
Am I misunderstanding anything or is this a bug in CMake? CMake version
is 2.6.2 on Linux.
Regards,
Martin
Virus checked by G DATA AntiVirus
Version: AVF 19.91 from 06.10.2008
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] WIN32_EXECUTABLE - Config specific settings for visual studio generated project files?
Thought this was handy enough to add a wiki entry: http://www.cmake.org/Wiki/VSConfigSpecificSettings Mike On Oct 7, 2008, at 12:49 AM, Jason Eubank wrote: Thanks Stefan, this worked well. My exact usage using your recommendations was as follows: if(WIN32) set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_DEBUG /SUBSYSTEM:CONSOLE) set_target_properties(WindowApplicationExample PROPERTIES RELWITHDEBINFO /SUBSYSTEM:CONSOLE) set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_RELEASE /SUBSYSTEM:WINDOWS) set_target_properties(WindowApplicationExample PROPERTIES MINSIZEREL /SUBSYSTEM:WINDOWS) endif(WIN32) This allows per-config setting of weather or not to use a console in visual studio, although it does not change the actual Subsytem setting in the Linker section, it does add it to the Additional Options setting in the Command Line section, which is then appended to the list of these settings and produces the same result. Thanks for the help! Jason On Mon, Oct 6, 2008 at 10:49 AM, Stefan Buschmann [EMAIL PROTECTED] wrote: Jason Eubank schrieb: Hello, I am wondering if it is possible to set the target property 'WIN32_EXECUTABLE' on a per-config basis (i.e. you can set link- flags on a per-config basis using LINK_FLAGS_Config). From reading the documentation this does not seem possible and if you set this property then all configurations (in Visual Studio) use the same subsystem setting. I don't know whether or not CMake is able to set a property on a per- configuration basis. I doubt this is possible (yet), but could be that I'm wrong here. But you could simply set the appropriate flags for a console/win32 application yourself, without using this flag at all. The only differences I could find between a win32 application and a console application are - Linker flag: /SUBSYSTEM:CONSOLE for console apps and / SUBSYSTEM:WINDOWS for win32 apps - Preprocessor definition: '_CONSOLE' for console apps Setting these using LINK_FLAGS_Config and COMPILE_DEFINITIONS_Config should do exactly what you want. The only problem I see that could possibly arise is that you can't depend on the WIN32_EXECUTABLE flag in your CMake file(s) anymore, to test for it or use it in any other way later. Another solution that comes to my mind is to always create a win32 application, and then open a console window later by using the win32 function 'AllocConsole' in your code. I never really needed this, but I know those functions are there to create or attach a console window to a win32 application. Have a look at the documentation for this function. Stefan ___ 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 mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Forcing a Qt version
Hi folks, I'm facing a curious problem here. I was using Qt-4.3.4 to compile ParaView in a Windows machine and it had been working fine but after installing a second version of Qt (4.4.2), CMake 2.6 (patch 2 RC-5) seems to be getting confused about which version it should use. Even pointing QT_QMAKE_EXECUTABLE to Qt-4.3.4, CMake insists in pointing all other stuffs to Qt-4.4.2 paths (QT_DOC_DIR, QT_INCLUDE_DIR, QT_LIBRARY_DIR and so on...). In my environment I have set QT_QMAKE_EXECUTABLE to Qt-4.3.4 but it's not solving the problem. Is there any other environment variable that could be used to force CMake in using the correct version of Qt? Regards Renato. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using CMake to bootstrap a build source tree via CVS/SVN
If you run EXECUTE_PROCESS to do a checkout before ADD_SUBDIRECTORY it should work fine. Do it conditionally though, or else you'll be doing checkouts constantly. You probably just want to do an update if the directory already exists... HTH, David On Thu, Oct 2, 2008 at 10:16 AM, kent williams [EMAIL PROTECTED]wrote: Right now we have a Slicer3 style 'getbuildtest' script to check out a bunch of Kitware packages in order to build an application. This basically works like this for all packages, check out the package configure it with cmake build it. Since the 'configure it with cmake' step is redundant over a series of patches, it seems like you should be able to user CMake to manage the whole process, but I'm not sure that's true. What I'd like to end up with the CMakeLists.txt file below. The question is this: I can certainly run CVS or SVN with EXECUTE_PROCESS, but will that happen early enough in the CMake config process that the ADD_SUBDIRECTORY clauses will be able to actually find the checked out subdirectories? Or should I just punt and have a 'check everything out' script I run before running CMake? PROJECT(MyProjectBuild) # # check out all the source from various places # # set all CMake variables for the packages ADD_SUBDIRECTORY(tk) ADD_SUBDIRECTORY(tcl) ADD_SUBDIRECTORY(Insight) ADD_SUBDIRECTORY(VTK) ADD_SUDIRECTORY(vtkinria3d) ADD_SUBDIRECTORY(MyProject) ___ 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] CMake problem with VTK and GDCM
Hello, I'm trying to use CMake to generate a makefile to compile a c++ program that uses VTK and GDCM ( http://info.fundp.ac.be/~scalande/problem/gdcmorthoplanes.cxx) Have a look to this picture to see a summary of the problem I meet : http://info.fundp.ac.be/~scalande/problem/gdcm_error12.PNG What does it mean ? It would be very nice if you could help me to resolve the problem. Thank you very much. Stéphane ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using cmake -E copy_directory with subversion
On Tue, Oct 7, 2008 at 5:15 AM, Aurélien Vallée
[EMAIL PROTECTED] wrote:
Hello,
I have come across a problem using CMake with SVN.
I have a src/shaders directory containing files with extension .glsl. I
need to create a rule to copy these files in my build directory, since my
program will need them at runtime.
For now, i have:
ADD_CUSTOM_TARGET( install_shaders ALL ${CMAKE_COMMAND} -E copy_directory
${CMAKE_HOME_DIRECTORY}/shaders/
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR} )
The problem is that _everything_ in src/shaders is copied to the build
directory, including the hidden .svn directory! So now after running a make,
i can't commit anything since SVN complains about having the same
destination URL for src/shaders and the build directory.
I tried to fix it with:
ADD_CUSTOM_TARGET( install_shaders ALL ${CMAKE_COMMAND} -E copy
${CMAKE_HOME_DIRECTORY}/shaders/*.glsl
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR} )
I would do a FILE(GLOB bla ${CMAKE_HOME_DIRECTORY}/shaders/*.glsl) instead.
2cts
--
Mathieu
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Install skips some targets
Hi, I have put together a simple build system of which I have attached to this mail a small sample. The sample builds two binaries (bin1 bin2) and two libraries (lib1 lib2) so that bin1 depends on lib1, bin2 depends on lib2, and lib1 depends on lib2. The build phase goes just fine but the installation step skips the bin1 and lib1 installation and I can't figure out why this happens. Following is the output of the build install process. Br, Petri Hodju 8888 host:~/misc/code/buildsys/make/build$ cmake .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- add_bin_dirs: -- + /home/pho/misc/code/buildsys/make/../src/bin/bin1 -- + /home/pho/misc/code/buildsys/make/../src/bin/bin2 -- add_lib_dirs: -- + /home/pho/misc/code/buildsys/make/../src/lib/lib1 -- + /home/pho/misc/code/buildsys/make/../src/lib/lib2 -- Configuring done -- Generating done -- Build files have been written to: /home/pho/misc/code/buildsys/make/build host:~/misc/code/buildsys/make/build$ make Scanning dependencies of target lib2hdrs [ 0%] ln -sf /home/pho/misc/code/buildsys/src/lib/lib2/lib2.h /home/pho/misc/code/buildsys/make/../inc/lib2.h [ 16%] Built target lib2hdrs Scanning dependencies of target lib2 [ 33%] Building CXX object /home/pho/misc/code/buildsys/lib/CMakeFiles/lib2.dir/lib2.cc.o Linking CXX shared library liblib2.so [ 33%] Built target lib2 Scanning dependencies of target bin2 [ 50%] Building CXX object /home/pho/misc/code/buildsys/bin/CMakeFiles/bin2.dir/bin2.cc.o Linking CXX executable bin2 [ 50%] Built target bin2 Scanning dependencies of target lib1hdrs [ 50%] ln -sf /home/pho/misc/code/buildsys/src/lib/lib1/lib1.h /home/pho/misc/code/buildsys/make/../inc/lib1.h [ 66%] Built target lib1hdrs Scanning dependencies of target lib1 [ 83%] Building CXX object /home/pho/misc/code/buildsys/lib/CMakeFiles/lib1.dir/lib1.cc.o Linking CXX shared library liblib1.so [ 83%] Built target lib1 Scanning dependencies of target hdr [ 83%] Built target hdr Scanning dependencies of target lib [ 83%] Built target lib Scanning dependencies of target bin1 [100%] Building CXX object /home/pho/misc/code/buildsys/bin/CMakeFiles/bin1.dir/bin1.cc.o Linking CXX executable bin1 [100%] Built target bin1 Scanning dependencies of target bin [100%] Built target bin Scanning dependencies of target project [100%] Built target project host:~/misc/code/buildsys/make/build$ make install [ 16%] Built target lib2hdrs [ 33%] Built target lib2 [ 50%] Built target bin2 [ 66%] Built target lib1hdrs [ 83%] Built target lib1 [ 83%] Built target hdr [ 83%] Built target lib [100%] Built target bin1 [100%] Built target bin [100%] Built target project Install the project... -- Install configuration: -- Installing: /home/pho/misc/code/buildsys/make/../ins/bin/bin2 -- Set runtime path of /home/pho/misc/code/buildsys/make/../ins/bin/bin2 to /home/pho/misc/code/buildsys/make/../ins/lib -- Up-to-date: /home/pho/misc/code/buildsys/make/../ins/bin/bin2 -- Installing: /home/pho/misc/code/buildsys/make/../ins/lib/liblib2.so -- Set runtime path of /home/pho/misc/code/buildsys/make/../ins/lib/liblib2.so to /home/pho/misc/code/buildsys/make/../ins/lib -- Up-to-date: /home/pho/misc/code/buildsys/make/../ins/lib/liblib2.so host:~/misc/code/buildsys/make/build$ 8888 buildsys.tar.gz Description: application/gzip ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Disable warnings in Visual Studio Express 2008
hi,
to disable useless warnings in visual studio 08, this works for me :
add_definitions( /W3 /D_CRT_SECURE_NO_WARNINGS /wd4005 /wd4996 /nologo )
On Mon, Oct 6, 2008 at 9:37 AM, Timenkov Yuri [EMAIL PROTECTED] wrote:
2008/10/2 user790 user790 [EMAIL PROTECTED]
Disabling specific warnings is a simple task so I thought I could do it
myself but I must admit defeat. A simple CMakeLists.txt like this won't
work.
project(testcmake)
# None of this works
#set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /wd4669)
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /wd4669 CACHE STRING Compilation
flags FORCE)
#set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -wd4669)
#set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -wd4669 CACHE STRING
Compilation flags FORCE)
add_executable(foo foo.cxx)
I have tried the same variants with COMPILE_FLAGS and
CMAKE_CXX_FLAGS_DEBUG / RELEASE with the same unsuccess.
1) What does your unsuccess mean?
2) You can edit flags from GUI, this should work.
3) If you want to override settings, you can set these flags without
caching. This usually works too.
I only have VS Express 2008 so I can't check whether I am doing something
wrong or if there is some issue with this particular IDE -- not even sure if
it is explicitely not supported.
Thanks for your help,
Tom
___
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 mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Paraview] Forcing a Qt version
Michael and Clinton I guess I'm facing a CMake's bug. I'm actually working with two Qt4 versions: Qt 4.4.2 (official distribution, including VS2008 integration) and Qt 4.3.4 (open source distribution). I've set the QTDIR variable as Michael suggested (in two places. Firstly in my own environment variables and secondly in the system's variables) but it had not worked. After that I downgraded CMake to 2.6.2 (official release), same problem. Clinton, setting the QT_QMAKE_EXECUTABLE in CMake was the first thing I tried (take a look at here http://www.nacad.ufrj.br/~rnelias/paraview/qt.JPG). It should be the easiest way. CMake keeps my set but mix with the other Qt stuffs with the newest version (4.4.2). Thus, when I try to launch the compiled PV I get an error message saying that it's not possible to find the entry point of the procedure [EMAIL PROTECTED]@@[EMAIL PROTECTED] in dynamic library QtGui4.dll. My guess, is that Visual Studio is qmaking with version 4.3.4 and linking against 4.4.2. By the way, should PV3 work with 4.4.2? Has anybody tried it? Regards Renato Clinton Stimpson wrote: If there's a qmake in your PATH, it takes precedence over whatever you set QTDIR to be. By the way, the use of QTDIR has been deprecated by Trolltech. Another thing you can do is set QT_QMAKE_EXECUTABLE in the cmake-gui before you hit configure for the first time, and it won't matter what your PATH is. Clint Michael Jackson wrote: Renato Assuming you really meant Qt 4.3.4 and NOT Qt 3.3.4 here is what you need to do. Remove everything from your build directory so we can start clean. Go to My Computer and add/check/set the QTDIR (Capitalization counts) to your Qt 4 installation. Launch CMakeSetup or CMake-GUI.exe and configure ParaView. You should at most get a warning about the version of Qt your are using and the required version. Everything _should_ work. Now, if you are really trying to use Qt 3 instead of Qt 4 then that is not supported. YOu need at least Qt 4.3 to build ParaView. Mike Jackson On Oct 7, 2008, at 10:31 AM, Renato N. Elias wrote: Hi Michael, there's something overriding my QTDIR because CMake still points to the wrong Qt version. I've set both QT_QMAKE_EXECUTABLE and QTDIR to 3.3.4 version, but CMake still returns me a warning that I'm using an unsupported version of Qt. Now I'm trying to understand all that CMake sintaxe in FindQt4.cmake and UseQt4.cmake modules. weird, isn't it?! Renato. Michael Jackson wrote: On Oct 7, 2008, at 9:26 AM, Renato N. Elias wrote: Hi folks, I'm facing a curious problem here. I was using Qt-4.3.4 to compile ParaView in a Windows machine and it had been working fine but after installing a second version of Qt (4.4.2), CMake 2.6 (patch 2 RC-5) seems to be getting confused about which version it should use. Even pointing QT_QMAKE_EXECUTABLE to Qt-4.3.4, CMake insists in pointing all other stuffs to Qt-4.4.2 paths (QT_DOC_DIR, QT_INCLUDE_DIR, QT_LIBRARY_DIR and so on...). In my environment I have set QT_QMAKE_EXECUTABLE to Qt-4.3.4 but it's not solving the problem. Is there any other environment variable that could be used to force CMake in using the correct version of Qt? Regards Renato. ___ ParaView mailing list [EMAIL PROTECTED] http://www.paraview.org/mailman/listinfo/paraview You can set QTDIR to the installation directory. CMake will try to use that variable if it finds it. Also, once the Qt libraries and stuff is set in a build directory it is pretty hard to get it to change. Clearing the build directory and starting out again with the QTDIR env variable set should help you find the correct version. Alternately you can open the CMakeCache.txt and remove all traces of ANY variable with QT in its name. This isn't exactly the preferred way to trouble shoot this problem but has worked in the past, plus saves all your compiled code from having to be recompiled. Mike Jackson ___ ParaView mailing list [EMAIL PROTECTED] http://www.paraview.org/mailman/listinfo/paraview ___ ParaView mailing list [EMAIL PROTECTED] http://www.paraview.org/mailman/listinfo/paraview ___ ParaView mailing list [EMAIL PROTECTED] http://www.paraview.org/mailman/listinfo/paraview ___ ParaView mailing list [EMAIL PROTECTED] http://www.paraview.org/mailman/listinfo/paraview ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] WIN32_EXECUTABLE - Config specific settings for visual studio generated project files?
Don't forget to add the preprocessor definition as well, because this might be used in some header files to check whether a WINDOWS or a CONSOLE app is going to be compiled. I test for this definition in my own project, and it might be even used inside the Windows headers, so this should always be defined when using Subsystem:Console. Also, shouldn't it be LINK_FLAGS_RELWITHDEBINFO and LINK_FLAGS_MINSIZEREL instead of RELWITHDEBINFO/MINSIZEREL as the property name? So I guess it should look like this (already changed this in the Wiki): if(WIN32) set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_DEBUG /SUBSYSTEM:CONSOLE) set_target_properties(WindowApplicationExample PROPERTIES COMPILE_DEFINITIONS_DEBUG _CONSOLE) set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_RELWITHDEBINFO /SUBSYSTEM:CONSOLE) set_target_properties(WindowApplicationExample PROPERTIES COMPILE_DEFINITIONS_RELWITHDEBINFO _CONSOLE) set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_RELEASE /SUBSYSTEM:WINDOWS) set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_MINSIZEREL /SUBSYSTEM:WINDOWS) endif(WIN32) Stefan Jason Eubank schrieb: Thanks Stefan, this worked well. My exact usage using your recommendations was as follows: if(WIN32) set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_DEBUG /SUBSYSTEM:CONSOLE) set_target_properties(WindowApplicationExample PROPERTIES RELWITHDEBINFO /SUBSYSTEM:CONSOLE) set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_RELEASE /SUBSYSTEM:WINDOWS) set_target_properties(WindowApplicationExample PROPERTIES MINSIZEREL /SUBSYSTEM:WINDOWS) endif(WIN32) This allows per-config setting of weather or not to use a console in visual studio, although it does not change the actual Subsytem setting in the Linker section, it does add it to the Additional Options setting in the Command Line section, which is then appended to the list of these settings and produces the same result. Thanks for the help! Jason On Mon, Oct 6, 2008 at 10:49 AM, Stefan Buschmann [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Jason Eubank schrieb: Hello, I am wondering if it is possible to set the target property 'WIN32_EXECUTABLE' on a per-config basis (i.e. you can set link-flags on a per-config basis using LINK_FLAGS_Config). From reading the documentation this does not seem possible and if you set this property then all configurations (in Visual Studio) use the same subsystem setting. I don't know whether or not CMake is able to set a property on a per-configuration basis. I doubt this is possible (yet), but could be that I'm wrong here. But you could simply set the appropriate flags for a console/win32 application yourself, without using this flag at all. The only differences I could find between a win32 application and a console application are - Linker flag: /SUBSYSTEM:CONSOLE for console apps and /SUBSYSTEM:WINDOWS for win32 apps - Preprocessor definition: '_CONSOLE' for console apps Setting these using LINK_FLAGS_Config and COMPILE_DEFINITIONS_Config should do exactly what you want. The only problem I see that could possibly arise is that you can't depend on the WIN32_EXECUTABLE flag in your CMake file(s) anymore, to test for it or use it in any other way later. Another solution that comes to my mind is to always create a win32 application, and then open a console window later by using the win32 function 'AllocConsole' in your code. I never really needed this, but I know those functions are there to create or attach a console window to a win32 application. Have a look at the documentation for this function. Stefan ___ CMake mailing list CMake@cmake.org mailto:CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to specify that a target link library is shared ?
Dear All, I am a recent user of CMake, and I cannot figure out how to tell CMake that a TARGET_LINK_LIBRARY is shared. I am working under Windows Xp with MS VisualStudio 2008, and the following is my CMakeLists file: PROJECT(Triangle) ADD_LIBRARY(triangle_lib SHARED triangle.c) ADD_EXECUTABLE(tricall tricall.c) TARGET_LINK_LIBRARIES(tricall triangle_lib) With the first target I am building a shared library 'triangle_lib.dll' and with the second target I'd like to build an executable 'tricall' that links to such library. Linking fails, as VS 2008 is looking for the static library 'triangle_lib.lib'. I have been searching the forums, and came across an example: TARGET_LINK_LIBRARIES(tricall SHARED triangle_lib), but then the linker looks for SHARED.lib, so 'SHARED' in not interpreted as a keyword but as the name of a library. Does anybody know how I should specify that I am linking against a shared library ? Thanks in advance for your advice, Best Regards, Andrea ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to specify that a target link library is shared ?
Hello, The problem is that you are not exporting any symbols in your library. On Windows even with shared libraries you have a .lib file that describes all the exported symbols. Andy On Tue, Oct 7, 2008 at 9:05 AM, Andrea Borsic [EMAIL PROTECTED]wrote: Dear All, I am a recent user of CMake, and I cannot figure out how to tell CMake that a TARGET_LINK_LIBRARY is shared. I am working under Windows Xp with MS VisualStudio 2008, and the following is my CMakeLists file: PROJECT(Triangle) ADD_LIBRARY(triangle_lib SHARED triangle.c) ADD_EXECUTABLE(tricall tricall.c) TARGET_LINK_LIBRARIES(tricall triangle_lib) With the first target I am building a shared library 'triangle_lib.dll' and with the second target I'd like to build an executable 'tricall' that links to such library. Linking fails, as VS 2008 is looking for the static library 'triangle_lib.lib'. I have been searching the forums, and came across an example: TARGET_LINK_LIBRARIES(tricall SHARED triangle_lib), but then the linker looks for SHARED.lib, so 'SHARED' in not interpreted as a keyword but as the name of a library. Does anybody know how I should specify that I am linking against a shared library ? Thanks in advance for your advice, Best Regards, Andrea ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Lets bike the world together http://legoandy.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to specify that a target link library is shared ?
2008/10/7 Andrea Borsic [EMAIL PROTECTED]: Dear All, I am a recent user of CMake, and I cannot figure out how to tell CMake that a TARGET_LINK_LIBRARY is shared. I am working under Windows Xp with MS VisualStudio 2008, and the following is my CMakeLists file: PROJECT(Triangle) ADD_LIBRARY(triangle_lib SHARED triangle.c) ADD_EXECUTABLE(tricall tricall.c) TARGET_LINK_LIBRARIES(tricall triangle_lib) With the first target I am building a shared library 'triangle_lib.dll' and with the second target I'd like to build an executable 'tricall' that links to such library. Linking fails, as VS 2008 is looking for the static library 'triangle_lib.lib'. I'm no windows expert but as far as I know triangle_lib.lib is not a static lib but a lib needed for compiling?or?linking a program which uses triangle_lib.dll. triangle_lib.lib should be built along with triangle_lib.dll when compiling the lib. Is triangle_lib.dll generated properly in the build directory? I have been searching the forums, and came across an example: TARGET_LINK_LIBRARIES(tricall SHARED triangle_lib), but then the linker looks for SHARED.lib, so 'SHARED' in not interpreted as a keyword but as the name of a library. Does anybody know how I should specify that I am linking against a shared library ? Normally you don't have to, moreover in this case your lib is a CMake target of the same project. CMake should find it without trouble. Is your CMakeLists.txt just as you wrote it? If you have 4 files you may post your whole project here? Which version of CMake do you use? -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to specify that a target link library is shared ?
On Tue, 7 Oct 2008, Andrea Borsic wrote: Dear All, I am a recent user of CMake, and I cannot figure out how to tell CMake that a TARGET_LINK_LIBRARY is shared. I am working under Windows Xp with MS VisualStudio 2008, and the following is my CMakeLists file: PROJECT(Triangle) ADD_LIBRARY(triangle_lib SHARED triangle.c) ADD_EXECUTABLE(tricall tricall.c) TARGET_LINK_LIBRARIES(tricall triangle_lib) With the first target I am building a shared library 'triangle_lib.dll' and with the second target I'd like to build an executable 'tricall' that links to such library. Linking fails, as VS 2008 is looking for the static library 'triangle_lib.lib'. I have been searching the forums, and came across an example: TARGET_LINK_LIBRARIES(tricall SHARED triangle_lib), but then the linker looks for SHARED.lib, so 'SHARED' in not interpreted as a keyword but as the name of a library. Doesn't Windows always need a .lib file, even if you will runtime link against a .dll? I seem to remember something like that from my Borland days. Does anybody know how I should specify that I am linking against a shared library ? Thanks in advance for your advice, Best Regards, Andrea ___ 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] How to specify that a target link library is shared ?
On Tue, 7 Oct 2008, Andy Lego wrote: Hello, The problem is that you are not exporting any symbols in your library. On Windows even with shared libraries you have a .lib file that describes all the exported symbols. Ah, I remembered right! Boudewijn ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Disabling warnings in Visual Studio Express 2008
2008/10/6 Werner Smekal [EMAIL PROTECTED] Hi, one thing I would try is add_definitions( -wd1234 ) since, cmake changes the - or / automatically for the compiler, as well as add_definitions( /wd1234 ) None of these work here. If that indeed works for other configurations, I find this inconsistency rather unpleasing... And as a last idea, you can set these warnings with #pragma calls in your sourcecode. Since this warning is compiler specific anyway, that's not a problem. Indeed. As this is my first attempt at using CMake for a project, I am using it to learn how to use this tool. This kind of problem and esp. the inconsistency that appears to exist between configurations makes it hard for the beginner to build trust... Thanks for your help, Tom ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Disable warnings in Visual Studio Express 2008
1) What does your unsuccess mean? It means that the outcome is a visual studio project which does not use the expected /wd flag for compilation. 2) You can edit flags from GUI, this should work. If you mean the Visual Studio GUI, sure, but I would have to do that everytime I re-run CMake, which is precisely what I try to avoid. If you mean the CMake GUI, that doesn't work either, because the CMakeLists.txt works as expected there. Meaning, the flag is already there in whichever variable I put it. 3) If you want to override settings, you can set these flags without caching. This usually works too. Sadly enough, over here it doesn't work either way. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to specify that a target link library is shared ?
Isn't the def files the defines the export symbols. Boudewijn Rempt wrote: On Tue, 7 Oct 2008, Andrea Borsic wrote: Dear All, I am a recent user of CMake, and I cannot figure out how to tell CMake that a TARGET_LINK_LIBRARY is shared. I am working under Windows Xp with MS VisualStudio 2008, and the following is my CMakeLists file: PROJECT(Triangle) ADD_LIBRARY(triangle_lib SHARED triangle.c) ADD_EXECUTABLE(tricall tricall.c) TARGET_LINK_LIBRARIES(tricall triangle_lib) With the first target I am building a shared library 'triangle_lib.dll' and with the second target I'd like to build an executable 'tricall' that links to such library. Linking fails, as VS 2008 is looking for the static library 'triangle_lib.lib'. I have been searching the forums, and came across an example: TARGET_LINK_LIBRARIES(tricall SHARED triangle_lib), but then the linker looks for SHARED.lib, so 'SHARED' in not interpreted as a keyword but as the name of a library. Doesn't Windows always need a .lib file, even if you will runtime link against a .dll? I seem to remember something like that from my Borland days. Does anybody know how I should specify that I am linking against a shared library ? Thanks in advance for your advice, Best Regards, Andrea ___ 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 mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] compilation errors of a program that uses VTK and GDCM via CMake
Hi, I'm trying to compile a source c++ that uses VTK and GDCM libraries ( http://info.fundp.ac.be/~scalande/problem/gdcmorthoplanes.cxxhttp://info.fundp.ac.be/%7Escalande/problem/gdcmorthoplanes.cxxif it is useful... ). I have installed the last versions of VTK and GDCM, and I use CMake to generate the Makefile. (I'm on Windows) But, when I compile, I always meet the same errors, even if I take other example files. The errors I receive are multiple definition of... I'm a newbie and I have tried everything today to manage to compile my examples but without any result. In order to be easier to understand the problem I meet, I created a little .png file that summarize my problem. http://info.fundp.ac.be/~scalande/problem/error01.PNGhttp://info.fundp.ac.be/%7Escalande/problem/error01.PNG I would really appreciate it if someone could help me by explaining me the problem or by giving solutions to resolve it. Thank you very much. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to specify that a target link library is shared ?
Hi All, Yes it is the .def file that defines the import/exports, but the linking stage fails before taking care of these aspects: it looks for triagle_lib.lib which is not there and stops before considering symbol resolutions. Thanks for your help, I will be reading all the emails that came in, Regards, Andrea Joshua L. Blocher wrote: Isn't the def files the defines the export symbols. Boudewijn Rempt wrote: On Tue, 7 Oct 2008, Andrea Borsic wrote: ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Setting Visual Studio Pre-Link Events with CMAKE
Is there anyway to set a Visual Studio Build Pre-Link Event command from a list file? I'm currently using a small utility program that uses DUMPBIN to strip out all the public methods from the object files to create the project's DEF file in creating a DLL. The .vcproj file would have the following entry if it was set: Tool Name=VCPreLinkEventTool Description=Generate $(ProjectName) def file CommandLine=$(BASEPATH)\local\windows\gendef\$(ConfigurationName)\gende f $(ConfigurationName)\$(InputName).def $(TargetFileName) $(IntDir)\*.obj / Thanks ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to specify that a target link library is shared ?
Hello,
The def file was always a bit of a mystery to me, since you do not specify
it on the command line but the linker just finds it magically. I much prefer
the import/export mechanism.
Here is what I typically did when I still did some Win32 programming:
Add the following code in your header file:
#if defined(_WIN32)
#if defined(mylib_EXPORTS)
#define MYLIB_EXPORT __declspec( dllexport )
#else
#define MYLIB_EXPORT __declspec( dllimport )
#endif
#else
#define MYLIB_EXPORT
#endif
Then every symbol you want to use outside the shared lib export like this:
class MYLIB_EXPORT someClass {
...
};
and
MYLIB_EXPORT void someFunc();
and so on.
Hope this helps.
Andy
On Tue, Oct 7, 2008 at 11:25 AM, Andrea Borsic
[EMAIL PROTECTED]wrote:
Hi All,
Yes it is the .def file that defines the import/exports, but the linking
stage fails before taking care of these aspects: it looks for
triagle_lib.lib which is not there and stops before considering symbol
resolutions.
Thanks for your help, I will be reading all the emails that came in,
Regards,
Andrea
Joshua L. Blocher wrote:
Isn't the def files the defines the export symbols.
Boudewijn Rempt wrote:
On Tue, 7 Oct 2008, Andrea Borsic wrote:
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Lets bike the world together
http://legoandy.com
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Output of ADD_CUSTOM_COMMAND generated multiple times
On 2008-10-07 10:22+0200 Martin Apel wrote:
Hi all,
I'm experiencing the following problem with ADD_CUSTOM_COMMAND:
The commands defined for it are executed multiple times, if multiple
targets depend on it and I run a parallel make afterwards.
An example makes this easier to understand:
PROJECT(Test)
cmake_minimum_required(VERSION 2.6)
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/a
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/a)
ADD_CUSTOM_TARGET(b
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/b
DEPENDS ${CMAKE_BINARY_DIR}/a)
ADD_CUSTOM_TARGET(c
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/c
DEPENDS ${CMAKE_BINARY_DIR}/a)
ADD_CUSTOM_TARGET(world)
ADD_DEPENDENCIES(world b)
ADD_DEPENDENCIES(world c)
You have run into a CMake limitation which I am told is an inevitable result
of their two-tier dependency approach (file dependencies and target
dependencies). To avoid the issue you have found for parallel builds you
must use the following constraint on your CMake logic.
If two targets file depend on the same custom_command output file you must
serialize them so they don't interfere with each other in a parallel build.
So to bring the above example into compliance with that rule you must
ADD_DEPENDENCIES(c b)
Don't ask me to justify the above rule (I am not that familiar with how
CMake implements its target dependencies and its file dependencies), but I
know that the above rule works.
PLplot has a huge thicket of file and target dependencies so I have run into
this wall any number of times with parallel build problems for various
combinations of PLplot build options. So far, I have always been able to
find a way to comply with the rule and thus get parallel builds to work
again, but it has not been that easy. For projects like PLplot with
complicated dependencies and a lot of different user options what we need is
a CMake dependency validator to make sure there is a warning message about
certain target file dependencies ruling out valid parallel builds when the
above rule is broken for the particular collection of options that the user
picks.
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] Output of ADD_CUSTOM_COMMAND generated multiple times
Alan W. Irwin wrote:
On 2008-10-07 10:22+0200 Martin Apel wrote:
Hi all,
I'm experiencing the following problem with ADD_CUSTOM_COMMAND:
The commands defined for it are executed multiple times, if multiple
targets depend on it and I run a parallel make afterwards.
An example makes this easier to understand:
PROJECT(Test)
cmake_minimum_required(VERSION 2.6)
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/a
COMMAND ${CMAKE_COMMAND} -E touch
${CMAKE_BINARY_DIR}/a)
ADD_CUSTOM_TARGET(b
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/b
DEPENDS ${CMAKE_BINARY_DIR}/a)
ADD_CUSTOM_TARGET(c
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/c
DEPENDS ${CMAKE_BINARY_DIR}/a)
ADD_CUSTOM_TARGET(world)
ADD_DEPENDENCIES(world b)
ADD_DEPENDENCIES(world c)
You have run into a CMake limitation which I am told is an inevitable
result
of their two-tier dependency approach (file dependencies and target
dependencies). To avoid the issue you have found for parallel builds you
must use the following constraint on your CMake logic.
If two targets file depend on the same custom_command output file you must
serialize them so they don't interfere with each other in a parallel build.
So to bring the above example into compliance with that rule you must
ADD_DEPENDENCIES(c b)
This is not correct. You don't have to serialize anything. You just
need all dependencies to be in place:
---
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/a
COMMAND ${CMAKE_COMMAND} -E touch
${CMAKE_BINARY_DIR}/a)
ADD_CUSTOM_TARGET(generate_a DEPENDS ${CMAKE_BINARY_DIR}/a)
ADD_CUSTOM_TARGET(b
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/b
DEPENDS ${CMAKE_BINARY_DIR}/a # file-level dependency
)
ADD_DEPENDENCIES(b generate_a) # target-level dependency
ADD_CUSTOM_TARGET(c
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/c
DEPENDS ${CMAKE_BINARY_DIR}/a # file-level dependency
)
ADD_DEPENDENCIES(c generate_a) # target-level dependency
ADD_CUSTOM_TARGET(world)
ADD_DEPENDENCIES(world b)
ADD_DEPENDENCIES(world c)
---
Now targets b and c and build in parallel, but neither will build until
'a' is generated.
The reason the separate target-level dependency is needed is because
targets b and c might not even know that 'a' is a generated file when
they are created in a different directory.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Output of ADD_CUSTOM_COMMAND generated multiple times
On 2008-10-07 16:09-0400 Brad King wrote: Now targets b and c and build in parallel, but neither will build until 'a' is generated. Thanks, Brad, for your further explanation and example. My method (which I started to use as a result of misinterpreting something you said on this topic before) appears to work, but yours is certainly more logical and will most likely result in faster parallel builds (because of the serialization used by my method). If your example isn't in the wiki, it should be. 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] [Paraview] Forcing a Qt version
I gave up and employed the dirtiest solution. Deleted Qt 4.3.4 and used Qt 4.4.2. Nothing more to choose, CMake finally got convinced that I only have one Qt version... ...In the end, instead of forcing a Qt version CMake forced me to delete one of them :o( Renato. Dominik Szczerba wrote: Yeah I used to fight with it too. It is far from clean. I do not recall now the details, but what did the trick for me was to specify QMAKE_EXECUTABLE (or something) and QT_DESIRED_VERSION (or something) Dominik On Tuesday 07 October 2008 05:11:56 pm Renato N. Elias wrote: Michael and Clinton I guess I'm facing a CMake's bug. I'm actually working with two Qt4 versions: Qt 4.4.2 (official distribution, including VS2008 integration) and Qt 4.3.4 (open source distribution). I've set the QTDIR variable as Michael suggested (in two places. Firstly in my own environment variables and secondly in the system's variables) but it had not worked. After that I downgraded CMake to 2.6.2 (official release), same problem. Clinton, setting the QT_QMAKE_EXECUTABLE in CMake was the first thing I tried (take a look at here http://www.nacad.ufrj.br/~rnelias/paraview/qt.JPG). It should be the easiest way. CMake keeps my set but mix with the other Qt stuffs with the newest version (4.4.2). Thus, when I try to launch the compiled PV I get an error message saying that it's not possible to find the entry point of the procedure [EMAIL PROTECTED]@@[EMAIL PROTECTED] in dynamic library QtGui4.dll. My guess, is that Visual Studio is qmaking with version 4.3.4 and linking against 4.4.2. By the way, should PV3 work with 4.4.2? Has anybody tried it? Regards Renato Clinton Stimpson wrote: If there's a qmake in your PATH, it takes precedence over whatever you set QTDIR to be. By the way, the use of QTDIR has been deprecated by Trolltech. Another thing you can do is set QT_QMAKE_EXECUTABLE in the cmake-gui before you hit configure for the first time, and it won't matter what your PATH is. Clint Michael Jackson wrote: Renato Assuming you really meant Qt 4.3.4 and NOT Qt 3.3.4 here is what you need to do. Remove everything from your build directory so we can start clean. Go to My Computer and add/check/set the QTDIR (Capitalization counts) to your Qt 4 installation. Launch CMakeSetup or CMake-GUI.exe and configure ParaView. You should at most get a warning about the version of Qt your are using and the required version. Everything _should_ work. Now, if you are really trying to use Qt 3 instead of Qt 4 then that is not supported. YOu need at least Qt 4.3 to build ParaView. Mike Jackson On Oct 7, 2008, at 10:31 AM, Renato N. Elias wrote: Hi Michael, there's something overriding my QTDIR because CMake still points to the wrong Qt version. I've set both QT_QMAKE_EXECUTABLE and QTDIR to 3.3.4 version, but CMake still returns me a warning that I'm using an unsupported version of Qt. Now I'm trying to understand all that CMake sintaxe in FindQt4.cmake and UseQt4.cmake modules. weird, isn't it?! Renato. Michael Jackson wrote: On Oct 7, 2008, at 9:26 AM, Renato N. Elias wrote: Hi folks, I'm facing a curious problem here. I was using Qt-4.3.4 to compile ParaView in a Windows machine and it had been working fine but after installing a second version of Qt (4.4.2), CMake 2.6 (patch 2 RC-5) seems to be getting confused about which version it should use. Even pointing QT_QMAKE_EXECUTABLE to Qt-4.3.4, CMake insists in pointing all other stuffs to Qt-4.4.2 paths (QT_DOC_DIR, QT_INCLUDE_DIR, QT_LIBRARY_DIR and so on...). In my environment I have set QT_QMAKE_EXECUTABLE to Qt-4.3.4 but it's not solving the problem. Is there any other environment variable that could be used to force CMake in using the correct version of Qt? Regards Renato. ___ ParaView mailing list [EMAIL PROTECTED] http://www.paraview.org/mailman/listinfo/paraview You can set QTDIR to the installation directory. CMake will try to use that variable if it finds it. Also, once the Qt libraries and stuff is set in a build directory it is pretty hard to get it to change. Clearing the build directory and starting out again with the QTDIR env variable set should help you find the correct version. Alternately you can open the CMakeCache.txt and remove all traces of ANY variable with QT in its name. This isn't exactly the preferred way to trouble shoot this problem but has worked in the past, plus saves all your compiled code from having to be recompiled. Mike Jackson ___ ParaView mailing list [EMAIL PROTECTED] http://www.paraview.org/mailman/listinfo/paraview ___ ParaView mailing list [EMAIL PROTECTED] http://www.paraview.org/mailman/listinfo/paraview ___ ParaView mailing list [EMAIL PROTECTED]
