Re: [cmake-developers] Adding the OpenRAVE library module
set_property(TARGET mysharedlib PROPERTY LINK_INTERFACE_LIBRARIES ) but wouldn't that also affect how the libraries are linked? for example, libopenrave target links to boost. and any module using libopenrave should still use boost. however the static libraries libopenrave links to like crlibm don't need to be handled this way. From what i understood in the documentation, I would have to set LINK_INTERFACE_LIBRARIES to all the non-static install libraries right? for the registry, the name could just be the version string right? so i would have 0.3.0 = C:\Program Files\OpenRAVE-0.3 where the configuration file is in: C:\Program Files\OpenRAVE-0.3\lib\cmake\openrave-0.3 thanks! rosen, 2011/4/15 Brad King brad.k...@kitware.com: On 04/15/2011 08:49 AM, Rosen Diankov wrote: thanks for the answers! for now i'm not sure if i want to spend time tweaking the LINK_INTERFACE_LIBRARIES property, it's getting a little too complicated just to get exports working right. It's probably just one line right after add_library(mysharedlib): set_property(TARGET mysharedlib PROPERTY LINK_INTERFACE_LIBRARIES ) Exporting targets is really the way to go. It is much nicer for apps. since we're not doing any find_library(OpenRAVE) calls, does that mean it is ok to use OpenRAVE_LIBRARY in my current setup? What would you recommend? The config file doesn't actually have to set a variable at all for any specific library if it uses imported targets. The application can just name the library. If you have several libraries that are typically used together then it might be convenient to list them in a variable like OpenRAVE_LIBRARIES. As for the registry, I just checked my windows and i have this key HKEY_LOCAL_MACHINE\\Software\\Kitware\\CMake 2.8.4 This is created by the installer of a specific CMake version and is related to CMake itself. however the cmake documentation says to put package specific stuff into: HKEY_LOCAL_MACHINE\\Software\\Kitware\\CMake\\Packages\\OpenRAVE where version is ignored. Is this correct? Yes. Your package does not care what version of cmake will be looking for it. i am just be setting the prefix to be read as the default key right? It should be a named value under the key. The name of the value is arbitrary. It is up to you to ensure that it doesn't conflict if multiple versions of your package are installed, so choose a name accordingly. It could even be something fancy like a hash of the install destination path, but that requires some non-trivial installer logic. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding the OpenRAVE library module
After thinking about it, it really doesn't make sense for static libraries to be part of the exports. rosen, 2011/4/15 Rosen Diankov rosen.dian...@gmail.com: set_property(TARGET mysharedlib PROPERTY LINK_INTERFACE_LIBRARIES ) but wouldn't that also affect how the libraries are linked? for example, libopenrave target links to boost. and any module using libopenrave should still use boost. however the static libraries libopenrave links to like crlibm don't need to be handled this way. From what i understood in the documentation, I would have to set LINK_INTERFACE_LIBRARIES to all the non-static install libraries right? for the registry, the name could just be the version string right? so i would have 0.3.0 = C:\Program Files\OpenRAVE-0.3 where the configuration file is in: C:\Program Files\OpenRAVE-0.3\lib\cmake\openrave-0.3 thanks! rosen, 2011/4/15 Brad King brad.k...@kitware.com: On 04/15/2011 08:49 AM, Rosen Diankov wrote: thanks for the answers! for now i'm not sure if i want to spend time tweaking the LINK_INTERFACE_LIBRARIES property, it's getting a little too complicated just to get exports working right. It's probably just one line right after add_library(mysharedlib): set_property(TARGET mysharedlib PROPERTY LINK_INTERFACE_LIBRARIES ) Exporting targets is really the way to go. It is much nicer for apps. since we're not doing any find_library(OpenRAVE) calls, does that mean it is ok to use OpenRAVE_LIBRARY in my current setup? What would you recommend? The config file doesn't actually have to set a variable at all for any specific library if it uses imported targets. The application can just name the library. If you have several libraries that are typically used together then it might be convenient to list them in a variable like OpenRAVE_LIBRARIES. As for the registry, I just checked my windows and i have this key HKEY_LOCAL_MACHINE\\Software\\Kitware\\CMake 2.8.4 This is created by the installer of a specific CMake version and is related to CMake itself. however the cmake documentation says to put package specific stuff into: HKEY_LOCAL_MACHINE\\Software\\Kitware\\CMake\\Packages\\OpenRAVE where version is ignored. Is this correct? Yes. Your package does not care what version of cmake will be looking for it. i am just be setting the prefix to be read as the default key right? It should be a named value under the key. The name of the value is arbitrary. It is up to you to ensure that it doesn't conflict if multiple versions of your package are installed, so choose a name accordingly. It could even be something fancy like a hash of the install destination path, but that requires some non-trivial installer logic. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012093]: Add brief configuration instructions in output
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12093 == Reported By:David Doria Assigned To: == Project:CMake Issue ID: 12093 Category: CTest Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2011-04-15 10:53 EDT Last Modified: 2011-04-15 10:53 EDT == Summary:Add brief configuration instructions in output Description: It would be nice to see something like: [doriad@localhost ITK]$ ctest -D Experimental Site: localhost.localdomain Build name: Linux-c++ (use cmake -DSITE:STRING=sitename -DBUILDNAME:STRING=buildname to change) == Issue History Date ModifiedUsername FieldChange == 2011-04-15 10:53 David DoriaNew Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding the OpenRAVE library module
On 04/15/2011 09:48 AM, Rosen Diankov wrote: From what i understood in the documentation, I would have to set LINK_INTERFACE_LIBRARIES to all the non-static install libraries right? Yes. It should list the libraries that applications should link when linking to your library. If your public headers include a public header from another library then that library should be listed. for the registry, the name could just be the version string right? Yes, if you don't care about multiple copies of the same version being installed on the same system ;) so i would have 0.3.0 = C:\Program Files\OpenRAVE-0.3 where the configuration file is in: C:\Program Files\OpenRAVE-0.3\lib\cmake\openrave-0.3 It should be the path to the directory containing the config file: 0.3.0 = C:\Program Files\OpenRAVE-0.3\lib\cmake\openrave-0.3 You can test it with the nightly build I linked earlier. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012095]: DetermineVSServicePack() does not properly sense service pack for vc100
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12095
==
Reported By:Doug Barbieri
Assigned To:
==
Project:CMake
Issue ID: 12095
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2011-04-15 18:09 EDT
Last Modified: 2011-04-15 18:09 EDT
==
Summary:DetermineVSServicePack() does not properly sense
service pack for vc100
Description:
During configuration, the function DetermineVSServicePack() does not properly
sense the presence of vc100 (Visual Studio 2010) service pack 1. This is because
the try_compile() CMake builtin runs cl.exe with the /nologo flag turned on.
This completely suppresses the version of the compiler in the output.
I wrote work around code so I could manually test the output:
file(WRITE ${CMAKE_BINARY_DIR}/return0.cc
int main() { return 0; }\n)
execute_process( COMMAND cl.exe return0.cc
OUTPUT_VARIABLE _output
ERROR_VARIABLE _error
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
)
file( REMOVE ${CMAKE_BINARY_DIR}/return0.cc )
string(REGEX MATCH Compiler Version [0-9]+.[0-9]+.[0-9]+.[0-9]+ for
_cl_version ${_error})
This works, but notice that there is an inconsistency between the command line
compiler (cl.exe) and the linker (linker.exe). The compiler outputs the version
string to stderr:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
...and the linker outputs to stdout:
Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
I didn't test earlier versions of the compiler to see if this was the case, but
there you go. You have to REGEX from stderr, not stdout in order to see the
version string.
Also, in the _DetermineVSServicePackFromCompiler() internal function, it tries
to match against 16.00.30319.01 instead of what vc100sp1 reports:
16.00.40219.01. And when it finds the match, the _version string is set to
vc100, not vc100sp1.
The way to solve this problem would be, I think, allow try_compile() to have an
option where the /nologo is suppressed for certain cases. Or use
execute_process() in the special case of vc100 (not preferable, I realize).
Steps to Reproduce:
Under Microsoft Windows (XP+), Install Visual Studio C++ 2010 (vc100) Service
Pack 1.
Create a very simple CMakeLists.txt file. Call DetermineVSServicePack( var ).
Notice that var remains unset after the call.
==
Issue History
Date ModifiedUsername FieldChange
==
2011-04-15 18:09 Doug Barbieri New Issue
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] RPATH on Mac
Dear all
I have a project in which I would like to use rpath on Mac OS.
Everything is going fine if I am building everything manually (i.e.
without CMake)
With CMake all is fine for the libs between the build and the
installation, all libs are processed with install_name_tool.
But nothing is done for the executable (checked from cmake_install.cmake)
In the build phase, I don't see any -Wl,-rpath,... added on the command line.
What do I miss there ?
I have been using:
SET(CMAKE_SKIP_BUILD_RPATH FALSE)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
SET(CMAKE_INSTALL_RPATH ${EXAMPLE_INSTALL_LIB_DIR})
as indicated in the Wiki.
Is there tool on the Mac to get rpath from the executable ?
Thanks for your help
Guillaume
--
PGP KeyID: 2048R/EA31CFC9 subkeys.pgp.net
___
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] CDash Dynamic Analysis
Hi This doesn't seem to be very easy, fun or well documented. I'v resolved to looking aroung the CTest source code to see what is going on. From what I'v found out, there seems to be some syntax to what the defect list contains! DefectList Defect Type=mystery/ DefectList I'm not certain if this is the easy way through, but it's the only way i see possible at the moment. I think i need to create my own program which eats program output and poops DynamicAnalysis.xml files. Perhaps i'll even add some way of configuration to it. -mika From: mika.raj...@patria.fi To: cmake@cmake.org Date: 14.04.2011 09:11 Subject:[CMake] CDash Dynamic Analysis Sent by:cmake-boun...@cmake.org Hi I'm trying to integrate custom tools to CDash Dynamic analysis. I'm not that certain on what is the way I should be going. Is there a way to tell cmake to pick up lines from a program as defects in the custom tool submission xml? Do i need to make a program that generates a valid xml file? If so, where do I find the documentation on how to do it? I downloaded the example XML files from http://www.itk.org/Wiki/CDash:XML here is a part of it Results / Log / /Test DefectList / EndDateTimeSep 15 19:36 CEST/EndDateTime ElapsedMinutes644.3/ElapsedMinutes /DynamicAnalysis /Site I think that I should modify the part DefectList. But this file doesn't give much information on what to do. There was a XML Schema file as well, but it wasn't of much use. /xs:element xs:element name=DefectList type=xs:string minOccurs=0 / xs:element name=EndDateTime type=xs:string minOccurs=0 / xs:element name=ElapsedMinutes type=xs:float minOccurs=0 / /xs:sequence -mika___ 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] Extended path for imported .proto files in the FindProtobuf module
Hi,
The current implementation (as of 2.3.8) of the FindProtobuf module
implicitly assumes that the imported .proto files are located only in the
${CMAKE_CURRENT_SOURCE_DIR}. This may not be true for more complex source
directory structure.
The attached patch allows users to override the default by setting an
external variable (PROTOBUF_IMPORT_DIRS) prior to the
PROTOBUF_GENERATE_CPP call.
It also fixes the bug #0010997 which si still pending in the bug tracking
system.
Regards
Mira
FindProtobuf_proto_import.patch
Description: Binary 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] Post-Build commands on custom targets are always executed?
Hi, I observe that a custom command attached to a custom target as POST-BUILD is launched on every build. Is that true? or is it a misconfiguration on my side? Bye, Oliver ___ 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] Post-Build commands on custom targets are always executed?
On 04/15/2011 11:22 PM, Oliver Buchtala wrote: Hi, I observe that a custom command attached to a custom target as POST-BUILD is launched on every build. Is that true? or is it a misconfiguration on my side? Bye, Oliver A custom target is always out of date, i.e. it is always rebuilt when it is visited - as a prerequisite of another target or due to the ALL clause, e.g., and since the target has been rebuilt, each associated POST_BUILD custom command is rerun. Thus, the behaviour you observed is correct, expected and reasonable, IMO. Regards, 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] Post-Build commands on custom targets are always executed?
Am 15.04.2011 23:48, schrieb Michael Hertling: On 04/15/2011 11:22 PM, Oliver Buchtala wrote: Hi, I observe that a custom command attached to a custom target as POST-BUILD is launched on every build. Is that true? or is it a misconfiguration on my side? Bye, Oliver A custom target is always out of date, i.e. it is always rebuilt when it is visited - as a prerequisite of another target or due to the ALL clause, e.g., and since the target has been rebuilt, each associated POST_BUILD custom command is rerun. Thus, the behaviour you observed is correct, expected and reasonable, IMO. Regards, 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 Yep. That's reasonable. Do have a suggestion how to get around a rerun of the post-build? Or how would you do a post-build after custom-target without being run when custom-target actually did nothing, i.e., custom target depends on custom command that did nothing? Bye, Oliver ___ 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] rebuild
I have a visual studio 2010 solution that I create with cmake. I have about 10 projects in the solution. Nine of these are open source libraries im using. The 10th is obviously the project I am currently working on. When I do a rebuild, it takes several minutes because it recompiles all the 3rd party libs. I would like rebuild to only rebuild my project as the 3rd party libs will not be changing. ___ 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-commits] CMake branch, next, updated. v2.8.4-1445-g4af24ea
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 4af24ea7936ec791dbe374c83ff1e6c5ad93028b (commit) via b590b261b606bb1f4b9ef1f036112428e7c156f6 (commit) via 342628aa202fb63713fc49948f365251f485fe02 (commit) from 139d284c4454fbccbc5c1ef84a9170b259a56e39 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4af24ea7936ec791dbe374c83ff1e6c5ad93028b commit 4af24ea7936ec791dbe374c83ff1e6c5ad93028b Merge: 139d284 b590b26 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Apr 15 10:54:54 2011 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Fri Apr 15 10:54:54 2011 -0400 Merge branch 'master' into next --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
