Re: [CMake] Compiler Test Failing on Windows 7
>> I wrote the batch script that Joe is using - the AMD64 in the build >> directory path is just a consequence of using %PROCESSOR_ARCHITECTURE% to >> create the build directory from the batch script and is purely a cosmetic >> issue. I'm failing to make sense (my fault only) of what's going on with this. Does this imply that %PROCESSOR_ARCHITECTURE% is set to something other than the true architecture of the machine you are running on ? From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Gregory Peele ARA/CFD Sent: Tuesday, January 05, 2010 5:27 PM To: cmake@cmake.org Subject: Re: [CMake] Compiler Test Failing on Windows 7 I wrote the batch script that Joe is using - the AMD64 in the build directory path is just a consequence of using %PROCESSOR_ARCHITECTURE% to create the build directory from the batch script and is purely a cosmetic issue. The CMake generator is what selects whether the build is 32-bit or 64-bit, and we definitely use the 32-bit Visual Studio 2005 generator. Since CMake is a 32-bit process, it sees the system as being 32-bit when processing CMakelists.txt, and is definitely using our configuration settings for 32-bit Windows. I'm especially puzzled by this behavior because the same project builds successfully in 64-bit Vista. Gregory Peele, Jr. Applied Research Associates, Inc. From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Smith Jack (Ext. - UGIS - UniCredit Group) Sent: Tuesday, January 05, 2010 8:51 AM To: cmake@cmake.org Subject: Re: [CMake] Compiler Test Failing on Windows 7 "The path is made from a batch script, and cmake is hardcoded to use 32bit on windows in the build scripts." I'm no expert, but it seems like you must have something wrong in the 'batch script' (or your environment). It looks like cmake thinks it's running on a AMD64 based system. I think the OS architecture is *normally* auto-detected, and to mistake a 32 bit OS for a 64 bit one seems like a pretty big error. Have you examined the script to be sure it's not misbehaving under Windows 7 - perhaps a list of known OSes doesn't include Win7 ? From: Joe L [mailto:superist_...@yahoo.com] Sent: Tuesday, January 05, 2010 2:44 PM To: Smith Jack (Ext. - UGIS - UniCredit Group); cmake@cmake.org Subject: Re: [CMake] Compiler Test Failing on Windows 7 I deleted the whole build directory before running the build. There isn't any modifying of the CMakeCache.txt as far as i know. Joe From: Smith Jack (Ext. - UGIS - UniCredit Group) To: "cmake@cmake.org" Sent: Tue, January 5, 2010 8:24:51 AM Subject: Re: [CMake] Compiler Test Failing on Windows 7 Do you have a stale CMakeCache.txt file somewhere ? It's *usually* perfectly safe to delete all occurrences of CMakeCache.txt within a project and have CMake regenerate them. I say usually, because I have no idea if you are modifying that file for some reason, although the practice is not recommended. From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Joe L Sent: Tuesday, January 05, 2010 2:09 PM To: cmake@cmake.org Subject: [CMake] Compiler Test Failing on Windows 7 After upgrading to windows 7, I'm getting errors when trying to run the cmake project generation step. It seems as though I'm unable to copy a file. I have the directory as a subdirectory of my users folder, so I didn't think it would be a permissions issue. Here is the error: CMake Error: Could not COPY_FILE. OutputFile: '' copyFile: 'C:/Users/joe/devel/RUGUD-devel/com.ara.engen.plugins.cpp/build/windows.AMD64.vc.8.release/CMakeFiles/CMakeDetermineCompilerABI_C.bin' Unable to find executable for try_compile: tried "C:/Users/joe/devel/RUGUD-devel/com.ara.engen.plugins.cpp/build/windows.AMD64.vc.8.release/CMakeFiles/CMakeTmp/cmTryCompileExec.exe" and "C:/Users/joe/devel/RUGUD-devel/com.ara.engen.plugins.cpp/build/windows.AMD64.vc.8.release/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.exe" and "C:/Users/joe/devel/RUGUD-devel/com.ara.engen.plugins.cpp/build/windows.AMD64.vc.8.release/CMakeFiles/CMakeTmp/Development/cmTryCompileExec.exe". CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:40 (FILE): file STRINGS file "C:/Users/joe/devel/RUGUD-devel/com.ara.engen.plugins.cpp/build/windows.AMD64.vc.8.release/CMakeFiles/CMakeDetermineCompilerABI_C.bin" cannot be read. Call Stack (most recent call first): C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:69 (CMAKE_DETERMINE_COMPILER_ABI) CMakeLists.txt:3 (PROJECT) CMake Error: Could not COPY_FILE. OutputFile: '' copyFile: 'C:/Users/joe/devel/RUGUD-devel/com.ara.engen.plugins.cpp/build/windows.AMD64.vc.8.release/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin' Unable to find executable for try_compile:
Re: [CMake] Does Cmake add 'standard' include paths ?
> -Original Message- > From: cmake-boun...@cmake.org > [mailto:cmake-boun...@cmake.org] On Behalf Of Alexander Neundorf > Sent: Tuesday, January 05, 2010 7:52 PM > To: cmake@cmake.org > Subject: Re: [CMake] Does Cmake add 'standard' include paths ? > > On Tuesday 05 January 2010, Smith Jack (Ext. - UGIS - > UniCredit Group) wrote: > > Generally I am using CMake successfully, and am generating > makefiles > > for Linux, Solaris, and Visual Studio 9. I recently used > the "Eclipse > > CDT4 - NMake Makefiles" generator, and then loaded the resulting > > project into my Eclipse environment under Windows XP. > > Which version of CMake, and which version of Eclipse and CDT > are you using ? CMake: cmake version 2.6-patch 2 Eclipse Platform: Version: 3.5.1.R35x_v20090910-9gEeG1_FthkNDSP2odXdThaOu9GFDPn83DGB7 Sorry, I'm not that familiar with Eclipse, how do I check CDT version ? > > > Eclipse then complains about missing include paths. The > problem is that I > > have not specified these 'missing' paths in my > CMakeLists.txt, or any > > file included by them. > > About which missing include paths does it complain ? > About include dirs you did not specify ? Example: Invalid project path: Include path not found (D:\SVN\trunk\MY_PROJECT\SUB_PROJECT\include). project-de...@debug pathentry Path Entry Problem Correct. Nowhere in my CMakeLists.txt files do I add that path to the inlcudes, yet they show up in the generated files. > > > Does Cmake automatically add PROJECT\include to every > project include > > No. > > > paths with the Eclipse generator ? If so, is there a way > to suppress > > this behavior ? > > Can you create a small example project which shows this issue > ? Then I could check whether I can reproduce it under Linux. > > Alex > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] intercomponent link dependencies?
Hi, I'm writing a FintMymodule.cmake file for a set of libraries (read: components), and with the given examples in the official CMake/Modules folder it comes along nicely. One thing I couldn't figure out now is how to set link dependencies between the different components; that is, if I link against component A not only libA is required for linking but also libB and libC. With regular libraries I understand I can pull this is in by TARGET_LINK_LIBRARIES.. Cheers, Nico ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] intercomponent link dependencies?
On 7. Jan, 2010, at 10:51 , Nico Schlömer wrote:
> Hi,
>
> I'm writing a FintMymodule.cmake file for a set of libraries (read:
> components), and with the given examples in the official CMake/Modules
> folder it comes along nicely.
>
> One thing I couldn't figure out now is how to set link dependencies
> between the different components; that is, if I link against component
> A not only libA is required for linking but also libB and libC. With
> regular libraries I understand I can pull this is in by
> TARGET_LINK_LIBRARIES..
>
> Cheers,
> Nico
>
One quick question: Are these libraries created by you? In that case you
shouldn't write a FindMymodule.cmake, but a MymoduleConfig.cmake (see the
documentation of find_package).
Anyhow, to define the transitive link dependencies you can either use
target_link_libraries(A LINK_INTERFACE_LIBRARIES B C) if your CMake is new
enough, or you can use set_target_properties(A PROPERTIES
LINK_INTERFACE_LIBRARIES "B;C"). Both solutions require that you use
add_library(X IMPORTED) (where X = A, B and C) and set their IMPORTED_LOCATION
property to the location on the file system. All of this is full automatic if
you write a MymoduleConfig.cmake, because then you can use
install_targets(A B C EXPORT MymoduleExports
ARCHIVE DESTINATION lib
LIBRARY DESTINATION lib
RUNTIME DESTINATION bin
PUBLIC_HEADER DESTINATION include
)
install(EXPORT MymoduleExports
NAMESPACE Mymodule_
DESTINATION share/mymodule/cmake
)
which will install a file
${CMAKE_INSTALL_PREFIX}/share/mymodule/cmake/MymoduleExports.cmake containing
all the IMPORT stuff and which you can INCLUDE in your MymoduleConfig.cmake.
I hope I could help a bit, otherwise tell us which case it is and I'll be able
to help more.
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] intercomponent link dependencies?
Hi Michael,
thanks for the explanations.
I'm indeed about to write a FindModule.cmake for a library which I did
*not* write, but to certain components of which I'd like to link
against using CMake (in a clean fashion).
I'm FOREACHing through the components of the library, and upon trying to set
ADD_LIBRARY( ${COMPONENT} )
cmake complains about
add_library cannot create target "A" because another target with the
same name already exists. The existing target is a static library created
in source directory "/path/to/A". See
documentation for policy CMP0002 for more details.
Okay, so it exists already? Fine. Let's then
SET_TARGET_PROPERTIES( ${COMPONENT} PROPERTIES
LINK_INTERFACE_LIBRARIES "B;C;" )
-- but again, cmake complains that
set_target_properties Can not find target to add properties to: A
TARGET_LINK_LIBRARIES doesn't work anyway as I'm not *building the
libraries (cmake says).
Hmmm...
Nico
On Thu, Jan 7, 2010 at 11:08 AM, Michael Wild wrote:
>
> One quick question: Are these libraries created by you? In that case you
> shouldn't write a FindMymodule.cmake, but a MymoduleConfig.cmake (see the
> documentation of find_package).
>
> Anyhow, to define the transitive link dependencies you can either use
> target_link_libraries(A LINK_INTERFACE_LIBRARIES B C) if your CMake is new
> enough, or you can use set_target_properties(A PROPERTIES
> LINK_INTERFACE_LIBRARIES "B;C"). Both solutions require that you use
> add_library(X IMPORTED) (where X = A, B and C) and set their
> IMPORTED_LOCATION property to the location on the file system. All of this is
> full automatic if you write a MymoduleConfig.cmake, because then you can use
>
> install_targets(A B C EXPORT MymoduleExports
> ARCHIVE DESTINATION lib
> LIBRARY DESTINATION lib
> RUNTIME DESTINATION bin
> PUBLIC_HEADER DESTINATION include
> )
>
> install(EXPORT MymoduleExports
> NAMESPACE Mymodule_
> DESTINATION share/mymodule/cmake
> )
>
> which will install a file
> ${CMAKE_INSTALL_PREFIX}/share/mymodule/cmake/MymoduleExports.cmake containing
> all the IMPORT stuff and which you can INCLUDE in your MymoduleConfig.cmake.
>
>
> I hope I could help a bit, otherwise tell us which case it is and I'll be
> able to help more.
>
> Michael
>
>
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] intercomponent link dependencies?
Hi Nico
In that case you need to do this:
add_library(${COMPONENT} IMPORTED)
set_target_properties(${COMPONENT} PROPERTIES
IMPORTED_LOCATION "${${COMPONENT}_LIBRARY}"
LINK_INTERFACE_LIBRARIES "${${COMPONENT}_LINK_INTERFACE_LIBRARIES}"
)
where each of the components X has a variable X_LIBRARY containing its path on
the system (e.g. determined by find_library(X_LIBRARY ...)) and a variable
X_LINK_INTERFACE_LIBRARIES which you have to set outside the foreach loop.
HTH
Michael
On 7. Jan, 2010, at 11:51 , Nico Schlömer wrote:
> Hi Michael,
>
> thanks for the explanations.
>
> I'm indeed about to write a FindModule.cmake for a library which I did
> *not* write, but to certain components of which I'd like to link
> against using CMake (in a clean fashion).
> I'm FOREACHing through the components of the library, and upon trying to set
>
> ADD_LIBRARY( ${COMPONENT} )
>
> cmake complains about
>
> add_library cannot create target "A" because another target with the
> same name already exists. The existing target is a static library created
> in source directory "/path/to/A". See
> documentation for policy CMP0002 for more details.
>
> Okay, so it exists already? Fine. Let's then
>
> SET_TARGET_PROPERTIES( ${COMPONENT} PROPERTIES
> LINK_INTERFACE_LIBRARIES "B;C;" )
>
> -- but again, cmake complains that
>
> set_target_properties Can not find target to add properties to: A
>
> TARGET_LINK_LIBRARIES doesn't work anyway as I'm not *building the
> libraries (cmake says).
>
> Hmmm...
> Nico
>
>
>
> On Thu, Jan 7, 2010 at 11:08 AM, Michael Wild wrote:
>>
>> One quick question: Are these libraries created by you? In that case you
>> shouldn't write a FindMymodule.cmake, but a MymoduleConfig.cmake (see the
>> documentation of find_package).
>>
>> Anyhow, to define the transitive link dependencies you can either use
>> target_link_libraries(A LINK_INTERFACE_LIBRARIES B C) if your CMake is new
>> enough, or you can use set_target_properties(A PROPERTIES
>> LINK_INTERFACE_LIBRARIES "B;C"). Both solutions require that you use
>> add_library(X IMPORTED) (where X = A, B and C) and set their
>> IMPORTED_LOCATION property to the location on the file system. All of this
>> is full automatic if you write a MymoduleConfig.cmake, because then you can
>> use
>>
>> install_targets(A B C EXPORT MymoduleExports
>> ARCHIVE DESTINATION lib
>> LIBRARY DESTINATION lib
>> RUNTIME DESTINATION bin
>> PUBLIC_HEADER DESTINATION include
>> )
>>
>> install(EXPORT MymoduleExports
>> NAMESPACE Mymodule_
>> DESTINATION share/mymodule/cmake
>> )
>>
>> which will install a file
>> ${CMAKE_INSTALL_PREFIX}/share/mymodule/cmake/MymoduleExports.cmake
>> containing all the IMPORT stuff and which you can INCLUDE in your
>> MymoduleConfig.cmake.
>>
>>
>> I hope I could help a bit, otherwise tell us which case it is and I'll be
>> able to help more.
>>
>> Michael
>>
>>
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] BUG: truncated directory names
Dear CMake developers,
I am building cmake 2.8.0 on Linux (CentOS 5.4) using the options:
./bootstrap --prefix=/cluster/apps/cmake/2.8.0 --datadir=share
--docdir=doc --mandir=man
Everything goes fine, except that when I execute "make install" the name of
some installation directories is truncated, i.e. "hare" instead of "share",
"oc" instead of "doc", "an" instead of "man":
[...]
-- Installing: /cluster/apps/cmake/2.8.0/share/Templates/CPackConfig.cmake.in
-- Installing: /cluster/apps/cmake/2.8.0/doc/cmsys/Copyright.txt
-- Installing: /cluster/apps/cmake/2.8.0/doc/cmzlib/Copyright.txt
-- Installing: /cluster/apps/cmake/2.8.0/doc/cmcurl/COPYING
-- Installing: /cluster/apps/cmake/2.8.0/doc/cmtar/COPYRIGHT
-- Installing: /cluster/apps/cmake/2.8.0/doc/cmcompress/Copyright.txt
-- Installing: /cluster/apps/cmake/2.8.0/doc/cmexpat/COPYING
-- Installing: /cluster/apps/cmake/2.8.0/hare/include/cmCPluginAPI.h
-- Installing: /cluster/apps/cmake/2.8.0/bin/ccmake
-- Installing: /cluster/apps/cmake/2.8.0/bin/cmake
-- Installing: /cluster/apps/cmake/2.8.0/bin/cpack
-- Installing: /cluster/apps/cmake/2.8.0/bin/ctest
-- Installing: /cluster/apps/cmake/2.8.0/an/man1/ctest.1
-- Installing: /cluster/apps/cmake/2.8.0/oc/ctest.txt
-- Installing: /cluster/apps/cmake/2.8.0/oc/ctest.html
[...]
As you can see in the excerpt above, this is not systematic; some files (e.g.
Copyright.txt) are installed in the right directories.
A simple workaround is to add a "/" before the directory names:
./bootstrap --prefix=/cluster/apps/cmake/2.8.0 --datadir=/share
--docdir=/doc --mandir=/man
Although this is not consistent with the documentation ("bootstrap --help"):
--docdir=DIRinstall documentation files in PREFIX/DIR
Best regards,
Olivier
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Does Cmake add 'standard' include paths ?
2010/1/7 Smith Jack (Ext. - UGIS - UniCredit Group) : > > CMake: cmake version 2.6-patch 2 This is a relatively old CMake version (Sept. 2008) could you by any chance try a more recent one? May be CMake 2.8.0 or even 2.6.4? http://www.cmake.org/cmake/resources/software.html > Eclipse Platform: Version: > 3.5.1.R35x_v20090910-9gEeG1_FthkNDSP2odXdThaOu9GFDPn83DGB7 > > Sorry, I'm not that familiar with Eclipse, how do I check CDT version ? In the Help menu go to "About Eclipse" then click on "CDT" icon this will show you your CDT version. >> About which missing include paths does it complain ? >> About include dirs you did not specify ? > > Example: > Invalid project path: Include path not found > (D:\SVN\trunk\MY_PROJECT\SUB_PROJECT\include). > project-de...@debug pathentry Path Entry Problem Is eclipse OK when you create a CDT project using eclipse (and not using CMake)? Note that you can suppress the spurious include from the project by hand. > Correct. Nowhere in my CMakeLists.txt files do I add that path to the > inlcudes, yet they show up in the generated files. Which generated files? .cproject, .project? Could you send us the corresponding set of CMakeLists.txt If not may be you can reproduce the problem with a "minimal" project, then you can send an archive of this minimal project on the list and we will try on our side in order to see what happen. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Does Cmake add 'standard' include paths ?
+Edited for brevity. > In the Help menu go to "About Eclipse" then click on "CDT" > icon this will show you your CDT version. Eclipse C/C++ Development Tools - Mylyn Bridge Version: 5.1.0.200909110608 Build id: 200909110608 > Is eclipse OK when you create a CDT project using eclipse > (and not using CMake)? I don't see an option for creating a CDT project, does it have another name (besides CDT?) > Which generated files? .cproject, .project? I'm opening the generated .project with Eclipse I have tracked down the only location I can find the offending include path The include directives are being done by way of a -ID:\SVN\trunk\MY_PROJECT\subdir\include which is found in a CMake generated file named flags.make which gets created in D:\SVN\trunk\MY_BUILD_DIR\My_PROJECT\subdir\CMakeFiles\subdir.dir > Could you send us the corresponding set of CMakeLists.txt That would be difficult because our project structure is relatively complicated, I'd have to include many files in the appropriate directory structure, and I'm not sure my company would allow it. > > If not may be you can reproduce the problem with a "minimal" > project, then you can send an archive of this minimal > project on the list and we will try on our side in order to > see what happen. > I've tried this, but I'm not having much luck, I'll spend some more time on it. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Does Cmake add 'standard' include paths ?
Never Mind, I found the errant include directive. I do apologize. > -Original Message- > From: cmake-boun...@cmake.org > [mailto:cmake-boun...@cmake.org] On Behalf Of Smith Jack > (Ext. - UGIS - UniCredit Group) > Sent: Thursday, January 07, 2010 9:34 AM > To: cmake@cmake.org > Subject: Re: [CMake] Does Cmake add 'standard' include paths ? > > > > -Original Message- > > From: cmake-boun...@cmake.org > > [mailto:cmake-boun...@cmake.org] On Behalf Of Alexander Neundorf > > Sent: Tuesday, January 05, 2010 7:52 PM > > To: cmake@cmake.org > > Subject: Re: [CMake] Does Cmake add 'standard' include paths ? > > > > On Tuesday 05 January 2010, Smith Jack (Ext. - UGIS - > UniCredit Group) > > wrote: > > > Generally I am using CMake successfully, and am generating > > makefiles > > > for Linux, Solaris, and Visual Studio 9. I recently used > > the "Eclipse > > > CDT4 - NMake Makefiles" generator, and then loaded the resulting > > > project into my Eclipse environment under Windows XP. > > > > Which version of CMake, and which version of Eclipse and > CDT are you > > using ? > > CMake: cmake version 2.6-patch 2 > Eclipse Platform: Version: > 3.5.1.R35x_v20090910-9gEeG1_FthkNDSP2odXdThaOu9GFDPn83DGB7 > > Sorry, I'm not that familiar with Eclipse, how do I check CDT > version ? > > > > > > Eclipse then complains about missing include paths. The > > problem is that I > > > have not specified these 'missing' paths in my > > CMakeLists.txt, or any > > > file included by them. > > > > About which missing include paths does it complain ? > > About include dirs you did not specify ? > > Example: > Invalid project path: Include path not found > (D:\SVN\trunk\MY_PROJECT\SUB_PROJECT\include). > project-de...@debug pathentry Path Entry Problem > > Correct. Nowhere in my CMakeLists.txt files do I add that > path to the inlcudes, yet they show up in the generated files. > > > > > > > Does Cmake automatically add PROJECT\include to every > > project include > > > > No. > > > > > paths with the Eclipse generator ? If so, is there a way > > to suppress > > > this behavior ? > > > > Can you create a small example project which shows this > issue ? Then I > > could check whether I can reproduce it under Linux. > > > > Alex > > ___ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Follow this link to subscribe/unsubscribe: > > http://www.cmake.org/mailman/listinfo/cmake > > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Google Tech Talk on CMake
Hi all, Last month, I gave a tech talk at the google NYC office. It is now up on youtube. Here is the link: http://www.youtube.com/watch?v=8Ut9o4OdSC0&feature=youtube_gdata Enjoy! -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake v2.8.0 ported to OS/2 - a question on DLL creation
Paul Smedley wrote: Windows does 8.3 mapping? Can you point to this in the cmake source? I wasn't aware of any windows restrictions of DLL filenames. Yes, there is a windows function to get a shore path name: GetShortPathName(tempPath, buffer, size); Setting up a dashboard should not be that hard if everything is working... If you have an existing build tree, you could just try this: ctest -D Experimental That should do a build and run the tests and it should show up on the dashboard. If you want to work on this, I can help you offline. -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] intercomponent link dependencies?
Hi Michael,
I added to the FindMypackage.cmake in the FOREACH(COMPONENT) loop the
following snipped
ADD_LIBRARY(${COMPONENT} STATIC IMPORTED)
SET_TARGET_PROPERTIES( ${COMPONENT} PROPERTIES
IMPORTED_LOCATION "${${UPPERCOMPONENT}_LIBRARY}"
LINK_INTERFACE_LIBRARIES
"${${COMPONENT}_LINK_INTERFACE_LIBRARIES}"
)
where "${${UPPERCOMPONENT}_LIBRARY}" is the path of the respective
library in the filesystem, and
"${${COMPONENT}_LINK_INTERFACE_LIBRARIES}" a semicolon-separated list
of dependencies of ${COMPONENT} (being either another component, or
something of the form /path/to/libfancy.a). CMake does create all the
Makefiles -- good -- but the dependency information doesn't sit in
there (?).
I expected that I can go like
FIND_PACKAGE( Mypackage COMPONENTS foocomp barcomp )
and that all the necessary stuff would be included automatically. --
Well, now that I think about it this is probably a pipe dream. What
would I further have to include?
Cheers,
Nico
On Thu, Jan 7, 2010 at 12:47 PM, Michael Wild wrote:
> Hi Nico
>
> In that case you need to do this:
>
> add_library(${COMPONENT} IMPORTED)
> set_target_properties(${COMPONENT} PROPERTIES
> IMPORTED_LOCATION "${${COMPONENT}_LIBRARY}"
> LINK_INTERFACE_LIBRARIES "${${COMPONENT}_LINK_INTERFACE_LIBRARIES}"
> )
>
> where each of the components X has a variable X_LIBRARY containing its path
> on the system (e.g. determined by find_library(X_LIBRARY ...)) and a variable
> X_LINK_INTERFACE_LIBRARIES which you have to set outside the foreach loop.
>
> HTH
>
> Michael
>
> On 7. Jan, 2010, at 11:51 , Nico Schlömer wrote:
>
>> Hi Michael,
>>
>> thanks for the explanations.
>>
>> I'm indeed about to write a FindModule.cmake for a library which I did
>> *not* write, but to certain components of which I'd like to link
>> against using CMake (in a clean fashion).
>> I'm FOREACHing through the components of the library, and upon trying to set
>>
>> ADD_LIBRARY( ${COMPONENT} )
>>
>> cmake complains about
>>
>> add_library cannot create target "A" because another target with the
>> same name already exists. The existing target is a static library created
>> in source directory "/path/to/A". See
>> documentation for policy CMP0002 for more details.
>>
>> Okay, so it exists already? Fine. Let's then
>>
>> SET_TARGET_PROPERTIES( ${COMPONENT} PROPERTIES
>> LINK_INTERFACE_LIBRARIES "B;C;" )
>>
>> -- but again, cmake complains that
>>
>> set_target_properties Can not find target to add properties to: A
>>
>> TARGET_LINK_LIBRARIES doesn't work anyway as I'm not *building the
>> libraries (cmake says).
>>
>> Hmmm...
>> Nico
>>
>>
>>
>> On Thu, Jan 7, 2010 at 11:08 AM, Michael Wild wrote:
>>>
>>> One quick question: Are these libraries created by you? In that case you
>>> shouldn't write a FindMymodule.cmake, but a MymoduleConfig.cmake (see the
>>> documentation of find_package).
>>>
>>> Anyhow, to define the transitive link dependencies you can either use
>>> target_link_libraries(A LINK_INTERFACE_LIBRARIES B C) if your CMake is new
>>> enough, or you can use set_target_properties(A PROPERTIES
>>> LINK_INTERFACE_LIBRARIES "B;C"). Both solutions require that you use
>>> add_library(X IMPORTED) (where X = A, B and C) and set their
>>> IMPORTED_LOCATION property to the location on the file system. All of this
>>> is full automatic if you write a MymoduleConfig.cmake, because then you can
>>> use
>>>
>>> install_targets(A B C EXPORT MymoduleExports
>>> ARCHIVE DESTINATION lib
>>> LIBRARY DESTINATION lib
>>> RUNTIME DESTINATION bin
>>> PUBLIC_HEADER DESTINATION include
>>> )
>>>
>>> install(EXPORT MymoduleExports
>>> NAMESPACE Mymodule_
>>> DESTINATION share/mymodule/cmake
>>> )
>>>
>>> which will install a file
>>> ${CMAKE_INSTALL_PREFIX}/share/mymodule/cmake/MymoduleExports.cmake
>>> containing all the IMPORT stuff and which you can INCLUDE in your
>>> MymoduleConfig.cmake.
>>>
>>>
>>> I hope I could help a bit, otherwise tell us which case it is and I'll be
>>> able to help more.
>>>
>>> Michael
>>>
>>>
>
>
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Setting Environment Variables on Windows (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: NONE
Fellow Cmake Users-
I am trying to set environment variables (namely PATH and PYTHONPATH) on
Windows during test execution. I utilize a configuration script which gets
converted from a .cmake.in to .cmake, then is used to call each of my tests.
The top of my .cmake.in looks as follows:
SET(TESTARG /path/to/whatever)
MESSAGE("TESTARG" ${TESTARG})
SET(ENV{PYTHONPATH} $ENV{PYTHONPATH}: TESTARG)
MESSAGE("PYTHONPATH:" $ENV{PYTHONPATH})
On Linux, this works perfectly. On Windows, however, there is no apparent
change to the environment variables (NOTE: I do change the ':' on Linux to
';' for Windows). It will output:
Linux:
TESTARG /path/to/whatever
PYTHONPATH: /whatever/my/python/path/was:/path/to/whatever
Windows:
TESTARG
PYTHONPATH: /whatever/my/python/path/was
It IS at least parsing through the commands, because if I put in a totally
invalid value to the SET command it will fail. It simply does not set either
the TESTARG (Cmake env. Variable) or PYTHONPATH (system env. Variable).
Has anyone had any luck setting environment variables on Windows?
Thanks for the assistance.
Emerson Sklar
Computer Scientist, High Performance Technologies, Inc.
Re: [CMake] Compiler Test Failing on Windows 7
Maybe we never explicitly stated this, but the system is in fact a 64-bit Windows OS, so %PROCESSOR_ARCHITECTURE% is correctly AMD64 for our system when viewed from a 64-bit process such as cmd.exe and our batch script. The project that we are building only supports 32-bit compilation in Windows at the moment, though (dang closed source third-party libraries!), which is why we use the 32-bit Visual Studio generators and have talked only about 32-bit stuff. Gregory Peele, Jr. Applied Research Associates, Inc. From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Smith Jack (Ext. - UGIS - UniCredit Group) Sent: Thursday, January 07, 2010 3:17 AM To: cmake@cmake.org Subject: Re: [CMake] Compiler Test Failing on Windows 7 >> I wrote the batch script that Joe is using - the AMD64 in the build >> directory path is just a consequence of using %PROCESSOR_ARCHITECTURE% to >> create the build directory from the batch script and is purely a cosmetic >> issue. I'm failing to make sense (my fault only) of what's going on with this. Does this imply that %PROCESSOR_ARCHITECTURE% is set to something other than the true architecture of the machine you are running on ? From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Gregory Peele ARA/CFD Sent: Tuesday, January 05, 2010 5:27 PM To: cmake@cmake.org Subject: Re: [CMake] Compiler Test Failing on Windows 7 I wrote the batch script that Joe is using - the AMD64 in the build directory path is just a consequence of using %PROCESSOR_ARCHITECTURE% to create the build directory from the batch script and is purely a cosmetic issue. The CMake generator is what selects whether the build is 32-bit or 64-bit, and we definitely use the 32-bit Visual Studio 2005 generator. Since CMake is a 32-bit process, it sees the system as being 32-bit when processing CMakelists.txt, and is definitely using our configuration settings for 32-bit Windows. I'm especially puzzled by this behavior because the same project builds successfully in 64-bit Vista. Gregory Peele, Jr. Applied Research Associates, Inc. From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Smith Jack (Ext. - UGIS - UniCredit Group) Sent: Tuesday, January 05, 2010 8:51 AM To: cmake@cmake.org Subject: Re: [CMake] Compiler Test Failing on Windows 7 "The path is made from a batch script, and cmake is hardcoded to use 32bit on windows in the build scripts." I'm no expert, but it seems like you must have something wrong in the 'batch script' (or your environment). It looks like cmake thinks it's running on a AMD64 based system. I think the OS architecture is *normally* auto-detected, and to mistake a 32 bit OS for a 64 bit one seems like a pretty big error. Have you examined the script to be sure it's not misbehaving under Windows 7 - perhaps a list of known OSes doesn't include Win7 ? From: Joe L [mailto:superist_...@yahoo.com] Sent: Tuesday, January 05, 2010 2:44 PM To: Smith Jack (Ext. - UGIS - UniCredit Group); cmake@cmake.org Subject: Re: [CMake] Compiler Test Failing on Windows 7 I deleted the whole build directory before running the build. There isn't any modifying of the CMakeCache.txt as far as i know. Joe From: Smith Jack (Ext. - UGIS - UniCredit Group) To: "cmake@cmake.org" Sent: Tue, January 5, 2010 8:24:51 AM Subject: Re: [CMake] Compiler Test Failing on Windows 7 Do you have a stale CMakeCache.txt file somewhere ? It's *usually* perfectly safe to delete all occurrences of CMakeCache.txt within a project and have CMake regenerate them. I say usually, because I have no idea if you are modifying that file for some reason, although the practice is not recommended. From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Joe L Sent: Tuesday, January 05, 2010 2:09 PM To: cmake@cmake.org Subject: [CMake] Compiler Test Failing on Windows 7 After upgrading to windows 7, I'm getting errors when trying to run the cmake project generation step. It seems as though I'm unable to copy a file. I have the directory as a subdirectory of my users folder, so I didn't think it would be a permissions issue. Here is the error: CMake Error: Could not COPY_FILE. OutputFile: '' copyFile: 'C:/Users/joe/devel/RUGUD-devel/com.ara.engen.plugins.cpp/build/windows.AMD64.vc.8.release/CMakeFiles/CMakeDetermineCompilerABI_C.bin' Unable to find executable for try_compile: tried "C:/Users/joe/devel/RUGUD-devel/com.ara.engen.plugins.cpp/build/windows.AMD64.vc.8.release/CMakeFiles/CMakeTmp/cmTryCompileExec.exe" and "C:/Users/joe/devel/RUGUD-devel/com.ara.engen.plugins.cpp/build/windows.AMD64.vc.8.release/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.exe" and "C:/Users/joe/devel/RUGUD-devel/com.ara.engen.plugins.cpp/build/windows.AMD64.vc.8.release/CMakeFiles/CMakeTmp/Devel
Re: [CMake] Setting Environment Variables on Windows (UNCLASSIFIED)
Hello -
This might help - from http://www.vtk.org/Wiki/CMake_Scripting_Of_CTest
# set any extra environment variables to use during the execution of
the script here:
SET (CTEST_ENVIRONMENT
)
My guess is it creates an empty/default environment when running tests
(rather than inheriting), and you need to pass in anything specific if you
want otherwise.
Hope this helps!
Ryan
On Thu, Jan 7, 2010 at 10:36 AM, Sklar, Emerson (Cont, ARL/CISD) <
emerson.sk...@arl.army.mil> wrote:
> Classification: * UNCLASSIFIED***
> Caveats: NONE
>
> Fellow Cmake Users-
> I am trying to set environment variables (namely PATH and PYTHONPATH) on
> Windows during test execution. I utilize a configuration script which gets
> converted from a .cmake.in to .cmake, then is used to call each of my
> tests. The top of my .cmake.in looks as follows:
>
> SET(TESTARG /path/to/whatever)
> MESSAGE("TESTARG" ${TESTARG})
> SET(ENV{PYTHONPATH} $ENV{PYTHONPATH}: TESTARG)
> MESSAGE("PYTHONPATH:" $ENV{PYTHONPATH})
>
> On Linux, this works perfectly. On Windows, however, there is no apparent
> change to the environment variables (NOTE: I do change the ':' on Linux to
> ';' for Windows). It will output:
>
> Linux:
> TESTARG /path/to/whatever
> PYTHONPATH: /whatever/my/python/path/was:/path/to/whatever
>
> Windows:
> TESTARG
> PYTHONPATH: /whatever/my/python/path/was
>
> It IS at least parsing through the commands, because if I put in a totally
> invalid value to the SET command it will fail. It simply does not set either
> the TESTARG (Cmake env. Variable) or PYTHONPATH (system env. Variable).
>
> Has anyone had any luck setting environment variables on Windows?
>
> Thanks for the assistance.
>
> Emerson Sklar
> Computer Scientist, *High Performance Technologies,
> Inc.*
Re: [CMake] Setting Environment Variables on Windows (UNCLASSIFIED)
Ryan Pavlik wrote:
Hello -
This might help - from http://www.vtk.org/Wiki/CMake_Scripting_Of_CTest
# set any extra environment variables to use during the execution of the script
here:
SET (CTEST_ENVIRONMENT
)
\
You need quotes around the set:
Something like this works:
SET(TESTARG /path/to/whatever)
MESSAGE("TESTARG" ${TESTARG})
SET(ENV{PYTHONPATH} "$ENV{PYTHONPATH};TESTARG")
MESSAGE("PYTHONPATH:" $ENV{PYTHONPATH})
-Bill
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoff...@kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] intercomponent link dependencies?
Hello,
My apologies in advance if I'm completely mis-reading your question and
if this answer seems way off base: just addressing what seemed like the
most likely issue from the info you provided. (This link below [1]
might help you get better results out of mailing lists.)
A script called by find_package(whatever) only normally sets variables
in CMake - it doesn't include or link any targets against any
libraries. (You might have several targets in one CMake project, each
that link against different libraries) So, in addition to the
find_package(Mypackage), in your CMakeLists.txt, you'll also want to do,
for example:
include_directories(${MYPACKAGE_INCLUDE_DIRS})
add_executable(myapp ${MYAPP_SOURCES})
target_link_libraries(myapp ${MYPACKAGE_FOOCOMP_LIBRARY}
${MYPACKAGE_BARCOMP_LIBRARY})
Note that according to the readme.txt in the modules directory of cmake
(and what seems to be convention), you'll note that your find module
variables should probably be named as above (
PACKAGEUPPER_COMPONENTUPPER_LIBRARY ). Additionally, once you've run
find_package_handle_standard_args, if(PACKAGEUPPER_FOUND), you will
probably want to do the following - this example assumes you have some
main library for the package that's always needed to link against that
package, and some additional optional libraries specified as components
(openscenegraph is an example of one of these types of packages)
set(PACKAGEUPPER_LIBRARIES ${PACKAGEUPPER_LIBRARY})
foreach(COMPONENT ${list_of_requested_and_found_components})
list(APPEND PACKAGEUPPER_LIBRARIES ${PACKAGEUPPER_COMPONENT_LIBRARY})
endforeach()
I've attached a rather simple example of this kind of script - you'd of
course have your component search loop and the additional foreach loop
explained above added to this basic structure. (and if you're doing it
by creating imported targets, you'll obviously use that code instead of
the direct file path code)
Hope this helps!
Ryan
[1] http://catb.org/~esr/faqs/smart-questions.html
On 01/07/2010 09:19 AM, Nico Schlömer wrote:
Hi Michael,
I added to the FindMypackage.cmake in the FOREACH(COMPONENT) loop the
following snipped
ADD_LIBRARY(${COMPONENT} STATIC IMPORTED)
SET_TARGET_PROPERTIES( ${COMPONENT} PROPERTIES
IMPORTED_LOCATION "${${UPPERCOMPONENT}_LIBRARY}"
LINK_INTERFACE_LIBRARIES
"${${COMPONENT}_LINK_INTERFACE_LIBRARIES}"
)
where "${${UPPERCOMPONENT}_LIBRARY}" is the path of the respective
library in the filesystem, and
"${${COMPONENT}_LINK_INTERFACE_LIBRARIES}" a semicolon-separated list
of dependencies of ${COMPONENT} (being either another component, or
something of the form /path/to/libfancy.a). CMake does create all the
Makefiles -- good -- but the dependency information doesn't sit in
there (?).
I expected that I can go like
FIND_PACKAGE( Mypackage COMPONENTS foocomp barcomp )
and that all the necessary stuff would be included automatically. --
Well, now that I think about it this is probably a pipe dream. What
would I further have to include?
Cheers,
Nico
On Thu, Jan 7, 2010 at 12:47 PM, Michael Wild wrote:
Hi Nico
In that case you need to do this:
add_library(${COMPONENT} IMPORTED)
set_target_properties(${COMPONENT} PROPERTIES
IMPORTED_LOCATION "${${COMPONENT}_LIBRARY}"
LINK_INTERFACE_LIBRARIES "${${COMPONENT}_LINK_INTERFACE_LIBRARIES}"
)
where each of the components X has a variable X_LIBRARY containing its path on
the system (e.g. determined by find_library(X_LIBRARY ...)) and a variable
X_LINK_INTERFACE_LIBRARIES which you have to set outside the foreach loop.
HTH
Michael
On 7. Jan, 2010, at 11:51 , Nico Schlömer wrote:
Hi Michael,
thanks for the explanations.
I'm indeed about to write a FindModule.cmake for a library which I did
*not* write, but to certain components of which I'd like to link
against using CMake (in a clean fashion).
I'm FOREACHing through the components of the library, and upon trying to set
ADD_LIBRARY( ${COMPONENT} )
cmake complains about
add_library cannot create target "A" because another target with the
same name already exists. The existing target is a static library created
in source directory "/path/to/A". See
documentation for policy CMP0002 for more details.
Okay, so it exists already? Fine. Let's then
SET_TARGET_PROPERTIES( ${COMPONENT} PROPERTIES
LINK_INTERFACE_LIBRARIES "B;C;" )
-- but again, cmake complains that
set_target_properties Can not find target to add properties to: A
TARGET_LINK_LIBRARIES doesn't work anyway as I'm not *building the
libraries (cmake says).
Hmmm...
Nico
On Thu, Jan 7, 2010 at 11:08 AM, Michael Wild wrote:
One quick question: Are these libraries created by you? In that case you
shouldn't write a FindMymodule.cmake, but a MymoduleConfig.cmake (see the
documentation of find_package).
Anyhow, to define the transitive link dependencies you can
Re: [CMake] FindCUDA with ITK
On Wed, Jan 6, 2010 at 11:00 PM, Luke Parkinson wrote: > Hello Everyone, > > I apologise in advance if this is the wrong way to revive an old topic, but > I wasn't sure how to reply to old threads in the mailing list and I'm new to > this list. I'm part of a team of developers looking at integrating CUDA > into the Insight Toolkit (http://www.itk.org/). People subscribing to the > mailing list over there might have heard from my colleague. > > Thanks to James Bigler and his FindCUDA.cmake module, we have been able to > get CUDA and ITK to link into the executable, but we're having a similar > problem to the previous post (included below just in case). I have created > several 'build environments' using this module with my own modifications > that include the SDK (as an aside, can anyone point me in the direction of > code that integrates C++ and CUDA without using cutil.h or cutil_inline.h?). > It works brilliantly with just the CUDA SDK, and the SDK plus our own C++ > CUDA utility programs, but when we include the ITK in the configuration, > building gives errors exactly like those above. I've attached my > modifications to the FindCUDA.cmake module (with a diff), and the > 'CMakeLists.txt's we're using in the root and source directories. > > We got the original FindCUDA.cmake from the svn repository, and based our > code on the driver examples. When we add our own CUDA/C++ code (files > omitted as code is still under development, permission is required), we get > the same errors as mentioned previously, along the lines of 'warning: > comparison between signed and unsigned integer expressions'. > > Just including ITK (without our own code, using the provided driver code > examples) > [Attached the corresponding files as ITKOnly_FindCUDA.cmake, > ITKOnly_root_CMakeLists.txt, ITKOnly_src_CMakeLists.txt] > > Any ideas or suggestions would be helpful. This isn't crippling (only > warnings), but it is annoying and could lead to problems later on if it has > to do with how the CMake module deals with C/C++ code. I also noticed with > that same module that there are a few variables that don't seem to do > anything. The example I found was CUDA_INCLUDE_DIRECTORIES (deprecated by > CUDA_INCLUDE_DIRS?). I assume that svn version was the most up-to-date, > please let me know if I am wrong. > snip... What versions of CUDA are you using? 2.3 or a 3.0 beta? Also, could you send the output of 'make VERBOSE=1' with CUDA_NVCC_FLAGS=-v for a single object compilation that has these warning? I would like to determine at which point these flags are causing problems. You could also attach (if possible) the cmake build script that is invoked by FindCUDA for the same object? Also, please make sure that CUDA_HOST_COMPILATION_CPP is ON (this can also be verified by me with the cuda_compilecmake file you can attach). There is also the CUDA_PROPAGATE_HOST_FLAGS that you could turn off, if you wish to manage all the host flag propagation manually by using the OPTION -Xcompiler combination. James ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CUDA, CMAKE, and an attempt to build nbody
On Wed, Jan 6, 2010 at 10:41 PM, Brian Davis wrote:
>
>
> On Tue, Jan 5, 2010 at 12:23 PM, James Bigler wrote:
>
>>
>>
>>> I ask my self two questions:
>>>
>>> 1) Why is CUDA_NVCC_FLAGS not set to some default build setting that
>>> would just work out of the box? - I get the answer to this question when I
>>> turn on CUDA_VERBOSE_BUILD_MODE - It is being set under the hood.
>>>
>>
>> I guess I don't understand your question. The CUDA_NVCC_FLAGS are the
>> flags used by all targets all the time. Occasionally additional flags are
>> added (such as -fPIC on certain systems as well as other flags) that make it
>> work based on your individual project configuration. It does work out of
>> the box for many applications.
>>
>
> I am trying to remember what the issue here was. I think it was that I
> could not see all the build settings AND (this is important) at the time I
> was using the dcmtk library and adding it to my project using
> add_subdirectroy( whereever/dcmtk ). DCMTK appears to force cmake backwards
> compatibility version which if used with FindCuda messes up the build. At
> least this is what I was experiencing. I am patching dcmtk with:
>
> diff -rupN dcmtk-3.5.4-original/CMakeLists.txt dcmtk-3.5.4/CMakeLists.txt
> --- dcmtk-3.5.4-original/CMakeLists.txt2010-01-04 10:05:14.426524200
> -0600
> +++ dcmtk-3.5.4/CMakeLists.txt2010-01-02 10:38:17.792807400 -0600
> @@ -8,9 +8,9 @@ ENDIF(NOT WIN32)
>
> # check required version of CMake
> CMAKE_MINIMUM_REQUIRED(VERSION 2.0)
> -IF(CMAKE_BACKWARDS_COMPATIBILITY GREATER 2.0.6)
> - SET(CMAKE_BACKWARDS_COMPATIBILITY 2.0.6 CACHE STRING "Latest version of
> CMake when this project was released." FORCE)
> -ENDIF(CMAKE_BACKWARDS_COMPATIBILITY GREATER 2.0.6)
> +#IF(CMAKE_BACKWARDS_COMPATIBILITY GREATER 2.0.6)
> +# SET(CMAKE_BACKWARDS_COMPATIBILITY 2.0.6 CACHE STRING "Latest version of
> CMake when this project was released." FORCE)
> +#ENDIF(CMAKE_BACKWARDS_COMPATIBILITY GREATER 2.0.6)
>
> # default build type
> SET(CMAKE_BUILD_TYPE RELEASE)
>
>
What kind of errors were you getting?
The FindCUDA.cmake script will definitely not work with anything less than
2.6.3. There are script features that require that version, so I'm not sure
what CMake would do in that case.
>
> This question turned out as I wrote the email to be a rhetorical question /
> documentation of my experience. CUDA_NVCC_FLAGS does not appear in the
> CMakeCache.txt (and I was expecting it to). CUDA_NVCC_FLAGS and friends in
> CMakeCache.txt:
>
>
>
> //Semi-colon delimit multiple arguments.
> CUDA_NVCC_FLAGS:STRING=
>
> //Semi-colon delimit multiple arguments.
> CUDA_NVCC_FLAGS_DEBUG:STRING=
>
> //Semi-colon delimit multiple arguments.
> CUDA_NVCC_FLAGS_MINSIZEREL:STRING=
>
> //Semi-colon delimit multiple arguments.
> CUDA_NVCC_FLAGS_RELEASE:STRING=
>
> //Semi-colon delimit multiple arguments.
> CUDA_NVCC_FLAGS_RELWITHDEBINFO:STRING=
>
>
Again these are the the user supplied flags that will be applied to
*everyone*. They don't take into consideration flags that were added on a
per configuration basis. This is why I added the CUDA_VERBOSE_BUILD flag,
since each target can have their own unique set of flags.
>
>
>>
>>> 2) There is a CUDA_TOOLKIT_INCLUDE, but no CUDA_SDK_INCLUDE (or _LIB)...
>>> why? (this would prevent ${CUDA_SDK_ROOT_DIR}/common/inc - see below)
>>>
>>>
>> As you found out the include directories for the CUDA SDK are not
>> supported by FindCUDA. Those libraries and headers are designed to be used
>> by the SDK, and not particularly by external packages. That doesn't prevent
>> you from doing so, but it was decided that because the CUDA SDK won't
>> maintain backward compatibility and is only designed for the SDK that
>> external use would not be supported by FindCUDA. As a compromise I chose to
>> have as a bare minimum a path to the SDK be supported for those who wished
>> to poke in the SDK to find things such as libraries or header files. There
>> is documentation in the help files and in the FindCUDA.cmake file as well as
>> examples of what to do with the CUDA_SDK_ROOT_DIR variable.
>>
>>
>
> Yes it looks as though from 2.2 to 2.3 and 3.0_Beta_1 they (NVIDIA) added a
> /C/ directory in the sdk and moved bin, common, etc there. If I could only
> create a ClairVoyantFindCUDA to know of future changes such as these.
>
>
Yes, it's hard to keep up with those guys, though there are some registry
keys and environment variables that I believe will persist (which is what I
try to make use of).
> So lets say that I take CMake compresed as a zip file
> cmake-2.8.0-win32-x86.zip and make it a part of my repository tree. Not
> installed in Windows using installer in an attempt to make the build
> computer not dependent on anything except the source control tool
> (subversion) and Visual Studio. I also take the CUDA SDK and CUDA Toolkit
> and put it in my tree after installing on build computer and ziping contents
> at C:\cuda and C:\Nvidia Corporati
Re: [CMake] intercomponent link dependencies?
Hi Ryan,
thanks very much for your answer.
For clarification, the package I would like to link against has (say)
three components A, B, C, where A at link time needs symbols of B
needs symbols of C needs symbols of some external libs.
I would like to make sure that the user can say
FIND_PACKAGE( mypackage COMPONENTS A )
and then find in some variable *all* the dependencies that are
required for linking, e.g.,
MYPACKAGE_A_LIBRARY="a;b;c;/usr/local/lib/libblas.a".
Right now (and which I'm not happy with), if a user would like to link
against liba.a, he or she has to know that libb.a, libc.a, and
/usr/local/lib/libblas.a have to be pulled in as well, and do so
manually.
If on the other hand I have the same dependency situation with
libraries that I *built*, the TARGET_LINK_LIBRARIES mechanism works
very well. If I understand correctly, this cannot be applied to
components in a FINDmypackage.cmake
Cheers,
Nico
On Thu, Jan 7, 2010 at 8:43 PM, Ryan Pavlik wrote:
> Hello,
>
> My apologies in advance if I'm completely mis-reading your question and if
> this answer seems way off base: just addressing what seemed like the most
> likely issue from the info you provided. (This link below [1] might help
> you get better results out of mailing lists.)
>
> A script called by find_package(whatever) only normally sets variables in
> CMake - it doesn't include or link any targets against any libraries. (You
> might have several targets in one CMake project, each that link against
> different libraries) So, in addition to the find_package(Mypackage), in
> your CMakeLists.txt, you'll also want to do, for example:
>
> include_directories(${MYPACKAGE_INCLUDE_DIRS})
> add_executable(myapp ${MYAPP_SOURCES})
> target_link_libraries(myapp ${MYPACKAGE_FOOCOMP_LIBRARY}
> ${MYPACKAGE_BARCOMP_LIBRARY})
>
> Note that according to the readme.txt in the modules directory of cmake (and
> what seems to be convention), you'll note that your find module variables
> should probably be named as above ( PACKAGEUPPER_COMPONENTUPPER_LIBRARY ).
> Additionally, once you've run find_package_handle_standard_args,
> if(PACKAGEUPPER_FOUND), you will probably want to do the following - this
> example assumes you have some main library for the package that's always
> needed to link against that package, and some additional optional libraries
> specified as components (openscenegraph is an example of one of these types
> of packages)
>
> set(PACKAGEUPPER_LIBRARIES ${PACKAGEUPPER_LIBRARY})
> foreach(COMPONENT ${list_of_requested_and_found_components})
> list(APPEND PACKAGEUPPER_LIBRARIES ${PACKAGEUPPER_COMPONENT_LIBRARY})
> endforeach()
>
>
> I've attached a rather simple example of this kind of script - you'd of
> course have your component search loop and the additional foreach loop
> explained above added to this basic structure. (and if you're doing it by
> creating imported targets, you'll obviously use that code instead of the
> direct file path code)
>
> Hope this helps!
>
> Ryan
>
>
> [1] http://catb.org/~esr/faqs/smart-questions.html
>
> On 01/07/2010 09:19 AM, Nico Schlömer wrote:
>>
>> Hi Michael,
>>
>> I added to the FindMypackage.cmake in the FOREACH(COMPONENT) loop the
>> following snipped
>>
>> ADD_LIBRARY(${COMPONENT} STATIC IMPORTED)
>> SET_TARGET_PROPERTIES( ${COMPONENT} PROPERTIES
>> IMPORTED_LOCATION
>> "${${UPPERCOMPONENT}_LIBRARY}"
>> LINK_INTERFACE_LIBRARIES
>> "${${COMPONENT}_LINK_INTERFACE_LIBRARIES}"
>> )
>>
>> where "${${UPPERCOMPONENT}_LIBRARY}" is the path of the respective
>> library in the filesystem, and
>> "${${COMPONENT}_LINK_INTERFACE_LIBRARIES}" a semicolon-separated list
>> of dependencies of ${COMPONENT} (being either another component, or
>> something of the form /path/to/libfancy.a). CMake does create all the
>> Makefiles -- good -- but the dependency information doesn't sit in
>> there (?).
>> I expected that I can go like
>>
>> FIND_PACKAGE( Mypackage COMPONENTS foocomp barcomp )
>>
>> and that all the necessary stuff would be included automatically. --
>> Well, now that I think about it this is probably a pipe dream. What
>> would I further have to include?
>>
>> Cheers,
>> Nico
>>
>>
>>
>> On Thu, Jan 7, 2010 at 12:47 PM, Michael Wild wrote:
>>
>>>
>>> Hi Nico
>>>
>>> In that case you need to do this:
>>>
>>> add_library(${COMPONENT} IMPORTED)
>>> set_target_properties(${COMPONENT} PROPERTIES
>>> IMPORTED_LOCATION "${${COMPONENT}_LIBRARY}"
>>> LINK_INTERFACE_LIBRARIES "${${COMPONENT}_LINK_INTERFACE_LIBRARIES}"
>>> )
>>>
>>> where each of the components X has a variable X_LIBRARY containing its
>>> path on the system (e.g. determined by find_library(X_LIBRARY ...)) and a
>>> variable X_LINK_INTERFACE_LIBRARIES which you have to set outside the
>>> foreach loop.
>>>
>>> HTH
>>>
>>> Michael
>>>
>>> On 7. Jan, 2010, at 11:51 , Nico Schlömer wrote:
>>>
>>>
Hi Michael,
thanks
[CMake] Cross compil and DESTDIR
Hi cmake mailing list !
When i cross compile with autotools, i used to do
$ ./configure --prefix=/usr/local ...
$ make install DESTDIR=${SYSROOT}
Now, with cmake i do
$ cmake source_dir -DCMAKE_INSTALL_PREFIX=/usr/local ...
$ make install DESTDIR=${SYSROOT}
Is it a good practice ?
What is the right way for doing a compilation for a foreign (embedded)
filesystem ?
Thank for your help.
Paul.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross compil and DESTDIR
Hi Paul,
yes, I do it in this way and it works good.
Only if the target system is Windows, there may be a Problem if prefix
is something like "C:/programs" ...
But in most embedded unix like systems, there is no problem.
Claus
On 07.01.2010, at 21:30, Paul Chavent wrote:
Hi cmake mailing list !
When i cross compile with autotools, i used to do
$ ./configure --prefix=/usr/local ...
$ make install DESTDIR=${SYSROOT}
Now, with cmake i do
$ cmake source_dir -DCMAKE_INSTALL_PREFIX=/usr/local ...
$ make install DESTDIR=${SYSROOT}
Is it a good practice ?
What is the right way for doing a compilation for a foreign
(embedded) filesystem ?
Thank for your help.
Paul.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] intercomponent link dependencies?
Ah, so if those components are always necessary (that is, A always needs
B, and B always needs C), there's no need to use the "components"
option. Just zip through them in this way - _LIBRARY (cache var) is a
single library, _LIBRARIES (not a cache var) is the list containing the
library and all its dependencies. If you use the _LIBRARIES variable,
you don't need to even mess around with the imported targets thing,
though you can if you really want to.
I've pasted an untested full example (done both ways - so actually 2
examples) using what you've explained in your last email. It's at the
bottom of this email, after the quote.
Hope this helps!
Ryan
On 01/07/2010 02:20 PM, Nico Schlömer wrote:
Hi Ryan,
thanks very much for your answer.
For clarification, the package I would like to link against has (say)
three components A, B, C, where A at link time needs symbols of B
needs symbols of C needs symbols of some external libs.
I would like to make sure that the user can say
FIND_PACKAGE( mypackage COMPONENTS A )
and then find in some variable *all* the dependencies that are
required for linking, e.g.,
MYPACKAGE_A_LIBRARY="a;b;c;/usr/local/lib/libblas.a".
Right now (and which I'm not happy with), if a user would like to link
against liba.a, he or she has to know that libb.a, libc.a, and
/usr/local/lib/libblas.a have to be pulled in as well, and do so
manually.
If on the other hand I have the same dependency situation with
libraries that I *built*, the TARGET_LINK_LIBRARIES mechanism works
very well. If I understand correctly, this cannot be applied to
components in a FINDmypackage.cmake
Cheers,
Nico
# - try to find MyPackage library
#
# Example-FindMyPackage.cmake
#
# This example is for a fairly in-depth library that has four
# internal dependencies as well as an external dependency.
# The dependency tree is described below, in graphviz/dot format, and you
# can remove the #'s from the following lines and run it through graphviz,
# with this command: dot dependencies.dot -O -Tpdf
#
# --- start of dependencies.dot ---
# digraph {
#BLAS;
#subgraph cluster_mypackage {
#label = "Components that are part of MyPackage";
#libmypackagecore -> libmypackagea;
#libmypackagea -> libmypackageb;
#libmypackageb -> libmypackagec;
#libmypackagec -> BLAS;
#}
# }
# --- end of dependencies.dot ---
#
# Because our imaginary component "c" requires BLAS and BLAS needs some
# linker flags, MYPACKAGE_..._LINKER_FLAGS joins the usual group of
# _LIBRARY/_LIBRARIES and _INCLUDE_DIR/_INCLUDE_DIRS variables. If
# you don't use a library like that, you don't need to include the
# lines dealing with that group of variables.
#
# Start of what would be a minimal module documentation blog:
#
# Cache Variables: (probably not for direct use in CMakeLists.txt)
# MYPACKAGE_LIBRARY
# MYPACKAGE_INCLUDE_DIR
# MYPACKAGE_a_LIBRARY
# MYPACKAGE_a_INCLUDE_DIR
# MYPACKAGE_b_LIBRARY
# MYPACKAGE_b_INCLUDE_DIR
# MYPACKAGE_c_LIBRARY
# MYPACKAGE_c_INCLUDE_DIR
#
# Non-cache variables you might use in your CMakeLists.txt:
# MYPACKAGE_FOUND
# MYPACKAGE_MARK_AS_ADVANCED - whether to mark our vars as advanced even
#if we don't find this library.
#
# MYPACKAGE_LIBRARIES
# MYPACKAGE_INCLUDE_DIRS
# MYPACKAGE_LINKER_FLAGS
#
# MYPACKAGE_a_LIBRARIES
# MYPACKAGE_a_INCLUDE_DIRS
# MYPACKAGE_a_LINKER_FLAGS
#
# MYPACKAGE_b_LIBRARIES
# MYPACKAGE_b_INCLUDE_DIRS
# MYPACKAGE_b_LINKER_FLAGS
#
# MYPACKAGE_c_LIBRARIES
# MYPACKAGE_c_INCLUDE_DIRS
# MYPACKAGE_c_LINKER_FLAGS
#
# Use this module this way:
# find_package(MyPackage)
# include_directories(MYPACKAGE_INCLUDE_DIRS)
# add_executable(myapp ${SOURCES})
# target_link_libraries(myapp ${MYPACKAGE_LIBRARIES})
# set_property(TARGET myapp PROPERTY LINK_FLAGS ${MYPACKAGE_LINKER_FLAGS})
#
# Requires these CMake modules:
# FindPackageHandleStandardArgs (CMake standard module)
#
# Original Author:
# 2009-2010 Ryan Pavlik
# http://academic.cleardefinition.com
# Iowa State University HCI Graduate Program/VRAC
find_library(MYPACKAGE_LIBRARY
NAMES mypackagecore
PATHS "${MYPACKAGE_ROOT}"
PATH_SUFFIXES lib)
find_path(MYPACKAGE_INCLUDE_DIR
NAMES mypackage/mypackage.h
PATHS "${MYPACKAGE_ROOT}"
PATH_SUFFIXES include)
# Assuming that the components are named libmypackagea, libmypackageb, etc
foreach(lib a b c)
find_library(MYPACKAGE_${lib}_LIBRARY
NAMES mypackage${lib}
PATHS "${MYPACKAGE_ROOT}"
PATH_SUFFIXES lib)
find_path(MYPACKAGE_${lib}_INCLUDE_DIR
NAMES mypackage/${lib}/${lib}.h
PATHS "${MYPACKAGE_ROOT}"
PATH_SUFFIXES include)
endforeach()
# see /usr/share/cmake-2.x/Modules/FindBLAS.cmake for the variables this
will define
if(NOT BLAS_FOUND)
find_package(BLAS QUIETLY)
endif()
# handle the QUIETLY and REQUIRED arguments and set xxx_FOUND to TRUE if
# all listed variables are TRUE
include(FindPackageHandleStandardArgs)
find_package_han
Re: [CMake] intercomponent link dependencies?
On Thu, 07 Jan 2010 15:54:33 -0600, Ryan Pavlik wrote: > If you use the _LIBRARIES variable, you don't need to even mess around > with the imported targets thing Dumping recursive dependencies in *_LIBRARIES causes overlinking, they should only be there when linking statically. Jed ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] intercomponent link dependencies?
Wow, thanks for the elaborate answer!
I learn a lot just going through the examples.
One thing for me to understand first:
> Ah, so if those components are always necessary (that is, A always needs B,
> and B always needs C), there's no need to use the "components" option.
Ah, I found the components thing neat for its syntax, as one can
(quite semantically) say
FIND_PACKAGE( MyPackage COMPONENTS coolCompOfMyPackage anotherOne )
# very much like done in FindBoost.cmake
Of course there's not only a,b,c, but a whole set of libraries a,...,z
under the roof of MyPackage with a more or less complicated dependency
tree. Also, it would depend on the installation of MyPackage whether
all the libraries are actually there; for example, and installation
with only "b" and "c" would be possible.
Anyway, instead of hardcoding a,b,c one could possible FOREACH through
a (hardcoded) list of components, such as
SET( ALL_LIBS "a" "b" "c" "d" [...] "z" )
I guess how one would do that with the above suggestion is to further
define MYPACKAGE_{$LIB}_FOUND, and then in the CMakeLists.txt
FIND_PACKAGE( MyPackage )
IF( MYPACKAGE_a_FOUND )
# add the necessary stuff to TARGET_LINK_LIBRARIES, for example
ELSE()
MESSAGE( FATAL_ERROR "Too bad, we need a." )
END()
The disadvantage I see here is that FindMypackage.cmake had to be
adapted every time a new library makes it into MyPackage. Also, the
code in CMakeLists.txt would get longer than what I thought would be
nice [being:
FIND_PACKAGE( MyPackage COMPONENTS "a" "g" "t" )
# FATAL_ERRORing out if either of a, g, t hasn't been found,
# otherwise providing a slim ${MyPACKAGE_LIBRARIES} to be appended to
# TARGET_LINK_LIBRARIES or something.
].
Cheers,
Nico
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CUDA, CMAKE, and an attempt to build nbody
>
>
> What kind of errors were you getting?
>
>
I would point to a URL on GMane for the thread titled "Build only what you
need in third party libs" , but it looks as though Gmane does not have all
the postings. I was getting bounces back from CMake mailing list due to
size of email.
Here is an excerpt from my local copy of the email:
I have the following line in one of my CMakeLists.txt files which I have
traced the issue down to.
add_subdirectory( ${THIRD_PARTY_SRC_DIR}/dcmtk-3.5.4 ./dcmtk-3.5.4 )
When I include this line the nbody app fails to build. When I remove it the
NBody app compiles.
The link error created when dcmtk is included in the project is:
1>Linking...
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
allocateNBodyArrays referenced in function "protected: virtual void __cdecl
BodySystemCUDA::_initialize(
int)" (?_initial...@bodysystemcuda@@mea...@z)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
registerGLBufferObject referenced in function "protected: virtual void
__cdecl BodySystemCUDA::_initialize(int)" (?_initial...@bodysystemcuda
@@mea...@z)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
unregisterGLBufferObject referenced in function "protected: virtual void
__cdecl BodySystemCUDA::_finalize(void)" (?_final...@bodysystemcuda
@@MEAAXXZ)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
deleteNBodyArrays referenced in function "protected: virtual void __cdecl
BodySystemCUDA::_finalize(void)" (?_final...@bodysystemcuda@@MEAAXXZ)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
setDeviceSoftening referenced in function "public: virtual void __cdecl
BodySystemCUDA::setSoftening(float)" (?setsoften...@bodysystemcuda@@uea...@z
)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
integrateNbodySystem referenced in function "public: virtual void __cdecl
BodySystemCUDA::update(float)" (?upd...@bodysystemcuda@@uea...@z)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
copyArrayFromDevice referenced in function "public: virtual float * __cdecl
BodySystemCUDA::getArray(enum BodySystem::BodyArray)"
(?getar...@bodysystemcuda@@ueaapeamw4bodyar...@bodysystem@@@Z)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
copyArrayToDevice referenced in function "public: virtual void __cdecl
BodySystemCUDA::setArray(enum BodySystem::BodyArray,float const *)"
(?setar...@bodysystemcuda@@ueaaxw4bodyar...@bodysystem@@p...@z)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol threadSync
referenced in function "public: virtual void __cdecl
BodySystemCUDA::synchronizeThreads(void)const "
(?synchronizethre...@bodysystemcuda@@UEBAXXZ)
1>C:\projects\NIH2009\source\branches\brian\build\Windows-6.1\ouput\bin\Debug\nbody.exe
: fatal error LNK1120: 9 unresolved externals
1>Build log was saved at "file://c:\projects\NIH2009\source\branches\brian
\build\dvip4-Win64-broken\cpp_source\app\nbody\nbody.dir\Debug\BuildLog.htm"
1>nbody - 10 error(s), 0 warning(s)
Which is a linker error where extern "C" files cannot be found. The
inclusion of a third party lib affects the project globally. Now
conversations above imply that CMake was never designed for this type of use
case. I have already had to change boost cmake build and will be submitting
my patch to that mailing list. It appears as though now dcmtk does not play
nice either. There are differences in the files... some I expect and others
I did not.
... it continues on and shows a diff of the project files that cmake
generates, which I will not post here for fear of the 40kb limit:
I notice a change from:
< set(source_file "C:/projects/NIH2009/source/
branches/brian/source/cpp/app/testing/cudaTests/nbody/src/bodysystemcuda.cu
")
To:
> set(source_file "C:/projects/NIH2009/source/branches/brian
/source/cpp/app/testing/cudaTests/nbody/src/nbody_kernel.cu")
involving bodysystemcuda.cu (bodysystemcuda.cpp declares ...
bodysystemcuda.cu defines) one of the very files which contain the
unresolved functions (allocateNBodyArrays and friends).
I then ask the question:
Can anyone point me on a path which would help me figure out what (global
project settings) in dcmtk could be causing these kinds of changes in my
unrelated nbody project?
Which I then end up answering my own question:
I removed (i.e. the force to use earlier version):
# check required version of CMake
CMAKE_MINIMUM_REQUIRED(VERSION 2.0)
#IF(CMAKE_BACKWARDS_COMPATIBILITY GREATER 2.0.6)
# SET(CMAKE_BACKWARDS_COMPATIBILITY 2.0.6 CACHE STRING "Latest version of
CMake when this project was released." FORCE)
#ENDIF(CMAKE_BACKWARDS_COMPATIBILITY GREATER 2.0.6)
>
>>
> Again these are the the user supplied flags that will be applied to
> *everyone*. They don't take into consideration flags that were added on a
> per configuration basis. This is why I added the CUDA_VERBOSE_BUILD flag,
> since each target can have their own unique set of flags.
>
>
>>
Yes and
Re: [CMake] mingw crosscompile error: invalid option `macosx-version-min=10.5' ?
On Wednesday 06 January 2010, Claus Klein wrote: > Yes, I did it again and again with rm -rf build. > Same result! > > As I said: "The problem occurs always when I run cmake again, no > matter of Windows or Windows-gcc is used." I don't see a way how cmake itself should come up with "Windows-gcc" as system name. So, if you start with a clean build dir, set CMAKE_SYSTEM_NAME to "Windows" properly (i.e. either via a toolchain file or via -D during the initial cmake invocation), how does your results look ? Alex ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] intercomponent link dependencies?
On Thu, Jan 7, 2010 at 4:00 PM, Jed Brown wrote:
> On Thu, 07 Jan 2010 15:54:33 -0600, Ryan Pavlik
> wrote:
> > If you use the _LIBRARIES variable, you don't need to even mess around
> > with the imported targets thing
>
> Dumping recursive dependencies in *_LIBRARIES causes overlinking, they
> should only be there when linking statically.
>
> Jed
>
So then actually should we all be doing imported targets in our find modules
then? I didn't realize it: most of the ones I looked at that come with
cmake didn't use it, so I just worked around it - wrote a function that can
safely remove those dupes instead :)
Is there any drawback (besides slightly longer code) to doing the imported
targets route?
Here's that CleanLibraryList.cmake file:
# - A smarter replacement for list(REMOVE_DUPLICATES) for library lists
#
# clean_library_list( [...]) - where
# WHATEVER_LIBRARIES is the name of a variable, such as a variable being
# created in a Find script.
#
# Removes duplicates from the list then sorts while preserving "optimized",
# "debug", and "general" labeling
#
# Requires CMake 2.6 or newer (uses the 'function' command)
#
# Original Author:
# 2009-2010 Ryan Pavlik
# http://academic.cleardefinition.com
# Iowa State University HCI Graduate Program/VRAC
function(clean_library_list _var)
# combine variable's current value with additional list items
set(_work ${${_var}} ${ARGN})
if(_work)
# Turn each of optimized, debug, and general into flags
# prefixed on their respective library (combining list items)
string(REGEX REPLACE "optimized;" "1CLL%O%" _work "${_work}")
string(REGEX REPLACE "debug;" "1CLL%D%" _work "${_work}")
string(REGEX REPLACE "general;" "1CLL%G%" _work "${_work}")
# clean up list
list(REMOVE_DUPLICATES _work)
list(SORT _work)
# Split list items back out again: turn prefixes into the
# library type flags.
string(REGEX REPLACE "1CLL%G%" "general;" _work "${_work}")
string(REGEX REPLACE "1CLL%D%" "debug;" _work "${_work}")
string(REGEX REPLACE "1CLL%O%" "optimized;" _work "${_work}")
# Return _work
set(${_var} ${_work} PARENT_SCOPE)
endif()
endfunction()
--
Ryan Pavlik
HCI Graduate Student
Virtual Reality Applications Center
Iowa State University
rpav...@iastate.edu
http://academic.cleardefinition.com
Internal VRAC/HCI Site: http://tinyurl.com/rpavlik
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] intercomponent link dependencies?
Not a problem - figured putting together some clean templates could
probably help me and my colleagues out too, anyway.
Your comment about the syntax makes me understand a bit better...
"MyPackage" isn't a name, it's a placeholder for one of the many general
packages of third party functionality that you use. I am guessing that
you're putting the detection for every library that your app can/must use
into one "find" module, when you actually probably should have a directory
in your source tree added to your CMAKE_MODULE_PATH that contains a large
number of find modules, some of which are interdependent (just like how the
example I sent uses find_package(BLAS) - which is a module that comes
bundled with cmake). Once you make enough cmake-based build systems, you'll
probably find yourself hanging on to a repository of assorted find modules.
I've pasted a simple example here, since it pretty well meshes with a common
use case.
The sample project uses OpenSceneGraph (plus its optional components osgDB
and osgUtil), as well as a large suite of libraries with internal
dependencies known as VR Juggler 2.2. OSG has modules that come with CMake,
while I had to make my own for VR Juggler.
-
cmake_minimum_required(VERSION 2.6)
project(minimal-vrjuggler-osg)
# Locally-developed modules dist'ed with this app
list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake)
# This should handle all dependencies, including OpenGL, GMTL, and so on
find_package(VRJuggler22 REQUIRED)
find_package(OpenSceneGraph REQUIRED osgUtil osgDB)
# Search for includes in these directories
include_directories(
${OPENSCENEGRAPH_INCLUDE_DIRS}
${VRJUGGLER22_INCLUDE_DIRS})
# Build the project
set(SOURCES
main.cpp
theapp.cpp
theapp.h)
add_executable(example ${SOURCES})
target_link_libraries(example ${OPENSCENEGRAPH_LIBRARIES}
${VRJUGGLER22_LIBRARIES})
---
That's an entire functional CMakeLists.txt file - though behind the scenes
we're linking to a ton of libraries in a ton of different directories.
(Read through the cmake docs online a few times - you got the imported
target thing but missed the "REQUIRED" flag that you can pass to
find_package... If you use the FindPackageHandleDefaultArgs call as
suggested by the readme.txt, it takes care of handling QUIET and REQUIRED
for you.)
So, I made a separate FindWhatever.cmake file for each library that belongs
to VR Juggler, and set it up like the examples from the last email, treating
them each as a separately-usable library (since they are). Since most of
the time, however, if you're writing a VR Juggler app, you're going to want
a large chunk of the tree by default, I made a FindVRJuggler22.cmake
"meta-module" sort of thing: means that for most folks, all that's needed in
the cmakelists is find_package(VRJuggler22 REQUIRED) or at most
find_package(VRJuggler22 COMPONENTS VRJOGL22 Tweek12). So, I have a whole
bundle of find modules written (actually, in total, I have ~20 find modules
in a directory I share between all my projects, with another ~20 modules
that provide functions: some utilities for find scripts, some for use
directly by a cmakelists) that I share between my projects, but because each
find module knows its own dependencies, it works it out. In that sense,
more files is better: it means you're keeping your find modules well-focused
and modular. (If the library comes in a separate zip/targz file, it
probably should have a separate find module - don't just smush them all into
one massive file.)
Here's the dependency tree for the VR Juggler find modules - each node is a
separate .cmake file that goes in a directory in my source tree, and each of
those find modules are set up just like the examples from the last email.
(in graphviz/DOT format) :
digraph {
// a module that, when included, provides a function definition that can
remove duplicate
// libraries from a _LIBRARIES list safely, without breaking the DEBUG
RELEASE GENERAL annotations
// I wrote this one, so it's in my project in a directory with the
custom find modules
CleanLibraryList;
subgraph cluster_bundled {
label = "Included with cmake 2.8.0";
FindBoost;
FindOpenSceneGraph -> { FindOpenThreads; FindosgALL; }
}
subgraph cluster_vrjuggler22 {
label = "VR Juggler 2.2 suite: All require CleanLibraryList and
CleanDirectoryList, and recommend FindFlagpoll";
FindTweek12 -> FindVPR20;
FindJCCL12 -> FindVPR20;
FindGadgeteer12 -> { FindJCCL12; FindVPR20; }
FindSonix12 -> FindVPR20;
FindVRJ22 -> { FindJCCL12; FindGadgeteer12; FindSonix12;
FindVPR20; }
FindVRJOGL22 -> FindVRJ22;
FindVRJuggler22 -> FindVRJOGL22;
} // commented out to make the diagram easier to read ->
{FindFlagpoll; CleanLibraryList; CleanDirectoryList;}
FindVPR20 -> { FindBoost; FindCPPDOM; }
FindGadgeteer12 -> FindGMTL;
FindSonix12 -> F
Re: [CMake] FindCUDA with ITK
- "James Bigler" wrote: > On Wed, Jan 6, 2010 at 11:00 PM, Luke Parkinson < lparkin...@vpac.org > > wrote: > > Hello Everyone, > > I apologise in advance if this is the wrong way to revive an old topic, but I > wasn't sure how to reply to old threads in the mailing list and I'm new to > this list. I'm part of a team of developers looking at integrating CUDA into > the Insight Toolkit ( http://www.itk.org/ ). People subscribing to the > mailing list over there might have heard from my colleague. > > Thanks to James Bigler and his FindCUDA.cmake module, we have been able to > get CUDA and ITK to link into the executable, but we're having a similar > problem to the previous post (included below just in case). I have created > several 'build environments' using this module with my own modifications that > include the SDK (as an aside, can anyone point me in the direction of code > that integrates C++ and CUDA without using cutil.h or cutil_inline.h?). It > works brilliantly with just the CUDA SDK, and the SDK plus our own C++ CUDA > utility programs, but when we include the ITK in the configuration, building > gives errors exactly like those above. I've attached my modifications to the > FindCUDA.cmake module (with a diff), and the 'CMakeLists.txt's we're using in > the root and source directories. > > We got the original FindCUDA.cmake from the svn repository, and based our > code on the driver examples. When we add our own CUDA/C++ code (files omitted > as code is still under development, permission is required), we get the same > errors as mentioned previously, along the lines of 'warning: comparison > between signed and unsigned integer expressions'. > > Just including ITK (without our own code, using the provided driver code examples) > [Attached the corresponding files as ITKOnly_FindCUDA.cmake, > ITKOnly_root_CMakeLists.txt, ITKOnly_src_CMakeLists.txt] > > Any ideas or suggestions would be helpful. This isn't crippling (only > warnings), but it is annoying and could lead to problems later on if it has > to do with how the CMake module deals with C/C++ code. I also noticed with > that same module that there are a few variables that don't seem to do > anything. The example I found was CUDA_INCLUDE_DIRECTORIES (deprecated by > CUDA_INCLUDE_DIRS?). I assume that svn version was the most up-to-date, > please let me know if I am wrong. > > snip... > > What versions of CUDA are you using? 2.3 or a 3.0 beta? > > Also, could you send the output of 'make VERBOSE=1' with CUDA_NVCC_FLAGS=-v > for a single object compilation that has these warning? I would like to > determine at which point these flags are causing problems. > > You could also attach (if possible) the cmake build script that is invoked by > FindCUDA for the same object? > > Also, please make sure that CUDA_HOST_COMPILATION_CPP is ON (this can also be > verified by me with the cuda_compilecmake file you can attach). > > There is also the CUDA_PROPAGATE_HOST_FLAGS that you could turn off, if you > wish to manage all the host flag propagation manually by using the OPTION > -Xcompiler combination. > > James > The CMake build script is identicle to the others I posted, just different source files and executable names. I included it anyway though, in case there was something I missed. I also double-checked the CUDA_HOST_COMPILATION flag, it's definitely set to 1. If you still think it would help, where can I find cuda_compile.cmake? I've attached the complete 'make VERBOSE=1' for both the FindCUDA.cmake sample code, and one with some of the warnings we've been getting for our own code. The CMakeCache.txt is from the ITK build I'm using, so you can see some of the variables it had defined internally. If you've seen the CMakeLists.txt I sent yesterday, it includes an ITK file USE_ITK_FILE (it's just in the recommendded build, points to the attached UseITK.cmake), which is where the new compile flags are introduced. Thanks for the tip about the CUDA_PROPAGATE_HOST_FLAGS and OPTION -Xcompiler, I'll try it out if all else fails. And thanks for the quick reply and you help with this, Luke cmake_itk2.tar.gz Description: GNU Zip compressed data ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] ExternalProject_Add inserting " around *'s "
For whatever command I am using if I insert a wild card to be passed in e.g.
INSTALL_COMMAND cp blah/* ${MY_STAGING}
becomes cp "blah/*"
which will then yield an error.
Is there some escape sequence I'm missing to avoid the quoting?
--
Cheers,
Timothy St. Clair
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] error while stage install of crosscompiled binaries
On 08.01.2010, at 02:25, Alexander Neundorf wrote:
On Thursday 07 January 2010, Claus Klein wrote:
Hi
i want to install a cross compiled (build host is a MAC OS X) project
to a temporary state dir to get an archive to distribute the
binaries.
The target is win32 (mingw), compiled to be installed at c:/usr as
CMAKE_INSTALL_PREFIX.
This prefix is used while compile the binaries, so I can't change it.
I think, that when I use DESTDIR while "make DESTDIR=/tmp/cmake
install", the device (C:) should be removed before to use it as part
of a path like this:
STRING(REGEX REPLACE "[A-Za-z:/]" "" CMAKE_INSTALL_PREFIX "$
{CMAKE_INSTALL_PREFIX}")
head cmake_install.cmake
# Install script for directory: /Users/clausklein/Workspace/c/libsmi/
trunk
#
# Set the install prefix
IF(NOT DEFINED CMAKE_INSTALL_PREFIX)
SET(CMAKE_INSTALL_PREFIX "C:/usr")
ENDIF(NOT DEFINED CMAKE_INSTALL_PREFIX)
STRING(REGEX REPLACE "/$" "" CMAKE_INSTALL_PREFIX "$
{CMAKE_INSTALL_PREFIX}")
. . . .
As you can see, PREFIX is appended to DESDIR without modification.
which is wrong in this special case.
Yes. So you would suggest to remove the drive letter from
CMAKE_INSTALL_PREFIX
when installing with DESTDIR set ?
Alex
Yes
I think it is never a valid path in this case to on Windows itself:
i.e. C:/tmp/cmake/C:/usr/lib/pkgconfig
I want to create a zip archive at /tmp/cmake to install it on Windows
under C:/
Claus
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] runtime error of ctest in windows VS2005
Dear Eric,
Thank you for your explanation. I think the mistake I made was that ctest is
used to compare the generated result with the expect result, such that the
return value 1 means that the program runs fine. However, what I was trying to
do is just to automatically run the executable with parameters. From what you
said, I guess I cannot use ctest to do this, and instead I need to write script
to do so.
Regards,
Xi Liang
梁茜
> Date: Wed, 6 Jan 2010 08:31:48 +0100
> Subject: Re: [CMake] runtime error of ctest in windows VS2005
> From: eric.noul...@gmail.com
> To: liangxi1986...@hotmail.com
> CC: cmake@cmake.org; insight-us...@itk.org
>
> 2010/1/6 Xi LIANG :
> > Dear all,
> > Im using Windows and the compiler is VS2005. I wrote a CMakeLists.txt file
> > to run a image registration program, which generates a executable named as
> > FFD_3D_mask.exe. This executable takes some arguments as names of input and
> > output files. The CMake file is written as the following, and it runs
> > properly and the generated executable also works fine by inputing the
> > arguments manually in the command window.
> > -
> > cmake_minimum_required(VERSION 2.8)
> >
> > PROJECT(FFD_3D_mask)
> > FIND_PACKAGE(ITK)
> > IF(ITK_FOUND)
> > INCLUDE(${ITK_USE_FILE})
> > ELSE(ITK_FOUND)
> > MESSAGE(FATAL_ERROR
> > "ITK not found. Please se t ITK_DIR.")
> > ENDIF(ITK_FOUND)
> > ADD_EXECUTABLE(FFD_3D_mask FFD_3D_mask.cxx )
> > TARGET_LINK_LIBRARIES(FFD_3D_mask ITKCommon ITKIO ITKNumerics ITKStatistics)
> >
> > Then I tried to automatically run the executable, without having to type the
> > arguments manually everytime. Then I added the following lines. I build the
> > executable first, and then build the RUN_TEST. The test is failed, and the
> > error message is attached. I am not sure whether the code I wrote was wrong,
> > or didnt build the test properly?
>
> First I would avoid calling your test "RUN_TEST" knowing that the
> CMake generated
> target is called "RUN_TESTS" this can lead to confusion at most.
> May be "GenMaskTest" or something more meaningfull would be good.
>
> However this shouldn't be the problem root.
>
> The default behavior of ctest is to check the returned value of the executable
> is your executable returning something different from 0 when it succeed?
>
> You said the test is failing but from what you give us we can only tell that
> C Test believe the test is failing, however could you check whether if the
> test
> is producing the expected files?
>
> Did you look at the failed log inside
> build\RUN_TESTS.dir\Debug\?
>
> I don't know how to do it from within Visual Studio but if you open a
> command line prompt
> and change dir to you build dir:
> file://c:\MRI\ITK\test\Registrati on\Deformable\3D_mask\build
>
> you may try to run ctest manually with verbose option:
>
> ctest -VV
>
> this should show you more details on the execution.
>
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org
_
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail
you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
