[cmake-developers] [CMake 0012066]: wrong using kstat in CMake/CTest
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12066 == Reported By:alexey kutumov Assigned To: == Project:CMake Issue ID: 12066 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-04-11 02:03 EDT Last Modified: 2011-04-11 02:03 EDT == Summary:wrong using kstat in CMake/CTest Description: Wrong parameter name passed to kstat, when using CTest under Solaris: syste_misc it must be: system_misc Steps to Reproduce: call CTest under SunOS Additional Information: Source\kwsys\SystemInformation.cxx bool SystemInformationImplementation::QuerySolarisInfo(); == Issue History Date ModifiedUsername FieldChange == 2011-04-11 02:03 alexey kutumov New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Adding the OpenRAVE library module
Dear CMake Developers, My name is Rosen Diankov and am the main developer for a robotics motion planning environment named OpenRAVE. http://openrave.programmingvision.com OpenRAVE is all managed with cmake and compiles on any *nix, windows, and mac osx. Most of the users (about 200 at the moment) are robotics researchers. Currently we're maintaining a FindOpenRAVE.cmake file for the latest stable versions here: https://openrave.svn.sourceforge.net/svnroot/openrave/tags/latest_stable/src/cppexamples/FindOpenRAVE.cmake We've followed the Modules/readme.txt and believe that the file is ready for official commits to cmake. Because we'll be always updating the URL, do you think we can setup some automated way of cmake grabbing the latest FindOpenRAVE.cmake whenever it gets updated, or is this something that I manage? In any case, I will be the maintainer. My id on Mantis, CDash, and Git is rdiankov, the email is rosen.dian...@gmail.com. When would it be possible to commit? thank you, rosen diankov, ___ 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/11/2011 02:20 AM, Rosen Diankov wrote: My name is Rosen Diankov and am the main developer for a robotics motion planning environment named OpenRAVE. Great, thanks for coming to us with this contribution. Because we'll be always updating the URL, do you think we can setup some automated way of cmake grabbing the latest FindOpenRAVE.cmake whenever it gets updated, or is this something that I manage? We manually review all changes submitted so an automated process will not work. However, as a maintainer you will be able to submit changes to our 'next' branch whenever you have them. In any case, I will be the maintainer. My id on Mantis, CDash, and Git is rdiankov, the email is rosen.dian...@gmail.com. When would it be possible to commit? See the publishing instructions link in step 5 here: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer Please send me (off-list) a public SSH key for authentication. --- Here are a few comments on the module's current status: # OPENRAVE_FOUND - if OpenRAVE is found # OPENRAVE_VERSION_STRING - the version found # OPENRAVE_CXXFLAGS - extra flags # OPENRAVE_INCLUDE_DIRS - include directories # OPENRAVE_LIBRARY_DIRS - link directories # OPENRAVE_LIBRARIES - libraries to link plugins with # OPENRAVE_CORE_LIBRARIES - libraries to link openrave run-time with That looks good at a glance. # deprecated # # OPENRAVE_LINK_DIRS - deprecated # OPENRAVE_LIBRARY_RELEASE - the relase version # OPENRAVE_LIBRARY - a default library, with priority debug. # OPENRAVE_LIBRARY - a default library, with priority debug. # OPENRAVE_CORE_LIBRARY You document OPENRAVE_LIBRARY twice. # Software License Agreement (Lesser GPL) This license is not acceptable. Do you have rights (e.g. permission from all copyright holders and past contributors) to submit this code under CMake's license? We use the OSI-approved BSD license. --- As a developer of OpenRAVE, please consider an alternative way to help CMake find your project. If you set up your project installation correctly then CMake doesn't even need a FindOpenRAVE module to locate it. When CMake sees find_package(OpenRAVE) it will look first for FindOpenRAVE.cmake in the CMAKE_MODULE_PATH and the CMake Modules directory, but if it doesn't find one then it instead enters config mode and starts looking for a package configuration file. In this mode it looks for a file called OpenRAVEConfig.cmake in places like prefix/lib/cmake/OpenRAVE/OpenRAVEConfig.cmake If you provide a file like this with your distribution then applications will not need a FindOpenRAVE.cmake file at all. This file is a CMake cross-platform equivalent of the openrave-config executable. See here for further information: http://www.cmake.org/Wiki/CMake/Tutorials/Packaging http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package Thanks, -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Ninja] Status and roadmap
On 04/11/2011 05:16 AM, Nicolas Desprès wrote: I have continued my work on the Ninja generator this weekend and I Great! Thanks for working on this. Here my roadmap: 1/ Configure and build an helloworld program with a shared library. 2/ Configure and build an helloworld program with a static library. 3/ Configure and build an helloworld program with a configured header. 4/ Configure and build an helloworld program with a custom target. 5/ Configure and build an helloworld program with a custom command. Looks good. 6/ Generate the 'clean' target. 7/ Generate the 'install' target. The 'install' target should be pretty easy. In all generators it is just a simple rule (depending on 'all') that runs cmake -P cmake_install.cmake with perhaps an extra -D option to indicate which configuration to install. As long as the generator obeys all the rules about where to put files in the build tree (e.g. CMAKE_RUNTIME_OUTPUT_DIRECTORY) then the install scripts should work. 8/ Handle dependency scanning using the special 'depfile' rule attribute of Ninja. 9/ Get CMake built using Ninja on Linux. I will see later for MacOSX and Windows support. 10/ Refactor common code with the UnixMakefile generator. Sounds good. The per-target generator design used by the Makefile generators and the VS 10 generator has proven to be the easiest to maintain. - I try to generate generic Ninja rules using Ninja variables, so that I can use Ninja's variable scoping to overload compilation flags on a per target/source file basis. This also reduces the number of Ninja rules generated. Using the $in and $out Ninja's special variables also simply the generation process. If you can get it to work this way, great! - The link rules do not use a link.txt file and cmake -E cmake_link_script. I thought its goal was to handle long command line, but apparently it does not since the command line in the link.txt file is not split. Did I miss a point in this implementation detail and should I rely on a link.txt file? Note that it would make the implementation more complex since I could not use $in and $out Ninja's special variables. You are correct. The link.txt is really just an implementation detail to work around command line length limits in Makefile rules. You do not need it if Ninja natively supports long lines. - Some code are picked-up from the UnixMakefile generator. I will see later how to refactor it. My code is still in a local branch and backup on another computer. If some one is interested in the code I can send the patches (they are rebased regulary on master). Though it is a bit too soon since only the very basics are implemented so far. I'm not sure if I'll have time to do a detailed review, I am interested in seeing the patch series. Thanks, -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
hi brad, Thanks for the advise, the license will not be issue and the OpenRAVEConfig.cmake idea is excellent! I have one question about case though. If it is OpenRAVE, then do all the variables have to be prefixed with the correct case OpenRAVE? In that case, would it be easier to do openrave-config.cmake and then have openrave_XXX variables set? what is your advice here? what about Windows? i doubt all users will be installing to C:\Program Files\... thanks, rosen, 2011/4/12 Brad King brad.k...@kitware.com: On 04/11/2011 02:20 AM, Rosen Diankov wrote: My name is Rosen Diankov and am the main developer for a robotics motion planning environment named OpenRAVE. Great, thanks for coming to us with this contribution. Because we'll be always updating the URL, do you think we can setup some automated way of cmake grabbing the latest FindOpenRAVE.cmake whenever it gets updated, or is this something that I manage? We manually review all changes submitted so an automated process will not work. However, as a maintainer you will be able to submit changes to our 'next' branch whenever you have them. In any case, I will be the maintainer. My id on Mantis, CDash, and Git is rdiankov, the email is rosen.dian...@gmail.com. When would it be possible to commit? See the publishing instructions link in step 5 here: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer Please send me (off-list) a public SSH key for authentication. --- Here are a few comments on the module's current status: # OPENRAVE_FOUND - if OpenRAVE is found # OPENRAVE_VERSION_STRING - the version found # OPENRAVE_CXXFLAGS - extra flags # OPENRAVE_INCLUDE_DIRS - include directories # OPENRAVE_LIBRARY_DIRS - link directories # OPENRAVE_LIBRARIES - libraries to link plugins with # OPENRAVE_CORE_LIBRARIES - libraries to link openrave run-time with That looks good at a glance. # deprecated # # OPENRAVE_LINK_DIRS - deprecated # OPENRAVE_LIBRARY_RELEASE - the relase version # OPENRAVE_LIBRARY - a default library, with priority debug. # OPENRAVE_LIBRARY - a default library, with priority debug. # OPENRAVE_CORE_LIBRARY You document OPENRAVE_LIBRARY twice. # Software License Agreement (Lesser GPL) This license is not acceptable. Do you have rights (e.g. permission from all copyright holders and past contributors) to submit this code under CMake's license? We use the OSI-approved BSD license. --- As a developer of OpenRAVE, please consider an alternative way to help CMake find your project. If you set up your project installation correctly then CMake doesn't even need a FindOpenRAVE module to locate it. When CMake sees find_package(OpenRAVE) it will look first for FindOpenRAVE.cmake in the CMAKE_MODULE_PATH and the CMake Modules directory, but if it doesn't find one then it instead enters config mode and starts looking for a package configuration file. In this mode it looks for a file called OpenRAVEConfig.cmake in places like prefix/lib/cmake/OpenRAVE/OpenRAVEConfig.cmake If you provide a file like this with your distribution then applications will not need a FindOpenRAVE.cmake file at all. This file is a CMake cross-platform equivalent of the openrave-config executable. See here for further information: http://www.cmake.org/Wiki/CMake/Tutorials/Packaging http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package Thanks, -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] MSVC LinkLibraryDependencies settable flag
Dear cmake devs, When creating a complex project with DLLs depending on static libraries in MSVC, it is necessary to set the LinkLibraryDependencies=true in the project file, or otherwise things won't work correctly. Because there's no option in cmake for this, we've been using the following hack: if( MSVC ) # set link library dependencies for visual studio in order to include symbols for other statically linked libs set_target_properties(libopenrave-core_static PROPERTIES STATIC_LIBRARY_FLAGS \ LinkLibraryDependencies=\true) endif() As you can see, the hack forces LinkLibraryDependencies=true to be declared, giving the desired behavior when surrounded with . is there a way we can get this option in cmake? thanks, rosen, ___ 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
hi brad, one more question. Even if a openrave-config.cmake file is present, we should also have a Findopenrave.cmake file right? After playing around with openrave-config.cmake, it turns out that openrave_FOUND gets set to TRUE no matter how hard openrave-config.cmake tries to set it to FALSE. (cmake 2.8.0) Also, all the examples use find_package_handle_standard_args, but that only sets the upper case variable OPENRAVE_FOUND.. does that mean i have to use all upper case? So I'm guessing that the fact that openrave-config.cmake is found means an installation exists and we should use the prefix set during cmake to fill the include directories, etc? In other words openrave-config.cmake would just look like: set(openrave_INCLUDE_DIRS XXX) set(openrave_LIBRARIES openrave) set(openrave_VERSION_STRING x.x.x) rosen, 2011/4/12 Brad King brad.k...@kitware.com: On 04/11/2011 02:20 AM, Rosen Diankov wrote: My name is Rosen Diankov and am the main developer for a robotics motion planning environment named OpenRAVE. Great, thanks for coming to us with this contribution. Because we'll be always updating the URL, do you think we can setup some automated way of cmake grabbing the latest FindOpenRAVE.cmake whenever it gets updated, or is this something that I manage? We manually review all changes submitted so an automated process will not work. However, as a maintainer you will be able to submit changes to our 'next' branch whenever you have them. In any case, I will be the maintainer. My id on Mantis, CDash, and Git is rdiankov, the email is rosen.dian...@gmail.com. When would it be possible to commit? See the publishing instructions link in step 5 here: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer Please send me (off-list) a public SSH key for authentication. --- Here are a few comments on the module's current status: # OPENRAVE_FOUND - if OpenRAVE is found # OPENRAVE_VERSION_STRING - the version found # OPENRAVE_CXXFLAGS - extra flags # OPENRAVE_INCLUDE_DIRS - include directories # OPENRAVE_LIBRARY_DIRS - link directories # OPENRAVE_LIBRARIES - libraries to link plugins with # OPENRAVE_CORE_LIBRARIES - libraries to link openrave run-time with That looks good at a glance. # deprecated # # OPENRAVE_LINK_DIRS - deprecated # OPENRAVE_LIBRARY_RELEASE - the relase version # OPENRAVE_LIBRARY - a default library, with priority debug. # OPENRAVE_LIBRARY - a default library, with priority debug. # OPENRAVE_CORE_LIBRARY You document OPENRAVE_LIBRARY twice. # Software License Agreement (Lesser GPL) This license is not acceptable. Do you have rights (e.g. permission from all copyright holders and past contributors) to submit this code under CMake's license? We use the OSI-approved BSD license. --- As a developer of OpenRAVE, please consider an alternative way to help CMake find your project. If you set up your project installation correctly then CMake doesn't even need a FindOpenRAVE module to locate it. When CMake sees find_package(OpenRAVE) it will look first for FindOpenRAVE.cmake in the CMAKE_MODULE_PATH and the CMake Modules directory, but if it doesn't find one then it instead enters config mode and starts looking for a package configuration file. In this mode it looks for a file called OpenRAVEConfig.cmake in places like prefix/lib/cmake/OpenRAVE/OpenRAVEConfig.cmake If you provide a file like this with your distribution then applications will not need a FindOpenRAVE.cmake file at all. This file is a CMake cross-platform equivalent of the openrave-config executable. See here for further information: http://www.cmake.org/Wiki/CMake/Tutorials/Packaging http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package Thanks, -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] DESTDIR behaviour with different variable name
I need behaviour that is available with DESTDIR (that is changing location of installation root after configuration and build is done) but with different name of environment variable (eg. MYDESTDIR). Is it possible with cmake? -- Regards, Tomasz Grobelny ___ 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] /DEFAULTLIB for Visual Studio 2010 generator
Hi, I ran into some strange behaviour when using the CMAKE_DEBUG_POSTFIX variable with the VS2010 generator. The solution generates fine and all the libraries of the project are built like they should in debug configuration with the _d postfix I specified. The problem is now that when linking one of the libraries, VS insists on linking a non-_d-version. I investigated in the linker log and found that apparently the /DEFAULTLIB option is set for this program. I then tried to recreate this with a simple test project, but wasn't successful so far. Has anyone encountered this behaviour or has any hints as to what could cause this? I'm using CMake 2.8.3 on Win7 64bit. Thanks! ___ 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] Choosing MPI installation
Hello, I'm a beginner and I apologize in case I'm asking a question that has already been answered. I would like to find mpi in my CMakeLists.txt and enable the user to set the mpi inlude and lib directories by setting say variables MY_MPI_INCLUDE_DIR and MY_MPI_LIB_DIR in cmake gui. Using find_package(MPI) works just fine for me, but once the package is found (and the variables MPI_LIBRARY and MPI_INCLUDE_PATH are set and cached), I cannot force cmake to search again for MPI in a different directory). Could you please give me a hint how to do this? How should I handle a situation where a user has possibly multiple mpi installations? Thank you very much. Best regards, Martin Vymazal This message was sent using IMP, the Internet Messaging Program. ___ 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] DESTDIR behaviour with different variable name
On 04/11/2011 03:16 PM, Tomasz Grobelny wrote: I need behaviour that is available with DESTDIR (that is changing location of installation root after configuration and build is done) but with different name of environment variable (eg. MYDESTDIR). Is it possible with cmake? export MYDESTDIR=$PWD/mydestdir make install DESTDIR=$MYDESTDIR HTH 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] Valgrind and CDash
On the CMake dashboard itself, we are running valgrind dashboards, too. One with ctest 2.8.1.20100608-g32b96. Then I set up identical dashboards, but using ctest 2.8.3 and ctest 2.8.4 after you reported this last month. They've been reporting just fine with all versions of ctest. Perhaps you could compare what we're doing in our script to what you're doing in yours to see if you can find the difference that's causing this problem... Here's a copy of the script we're using with ctest 2.8.4: http://www.cdash.org/CDash/viewNotes.php?buildid=959977 Let us know if you figure it out... Or perhaps send your ctest script along and somebody here can spot something unusual about it. From my perspective, things are working just fine with valgrind, and ctest 2.8.1., 2.8.3 and 2.8.4.. Thx, David On Mon, Apr 11, 2011 at 9:52 AM, Allen D Byrne b...@hdfgroup.org wrote: Anyone have a clue how we can get CDash to display the valgrind report properly. Last month I noted that with cmake 2.8.4 we could not get the valgrind reports displayed properly, the report shows the raw compressed (or otherwise encrypted data). We have the same problem using CMake 2.8.3, 2.8.2 is correct. We are using CDash 1.8.2. Two different linux machines one 32 the other 64. The DynamicAnalysis_XXX.log file in the build/Temporary folder has all the proper data. The .xml file log data is what is displayed without any translation. Allen ___ 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] DESTDIR behaviour with different variable name
On Mon, 11 Apr 2011 16:07:36 +0200, Michael Wild them...@gmail.com wrote: On 04/11/2011 03:16 PM, Tomasz Grobelny wrote: I need behaviour that is available with DESTDIR (that is changing location of installation root after configuration and build is done) but with different name of environment variable (eg. MYDESTDIR). Is it possible with cmake? export MYDESTDIR=$PWD/mydestdir make install DESTDIR=$MYDESTDIR Ok, but is there a way to achieve the same effect so that the user can type just make install and not know anything about DESTDIR environment variable (provided he knows about MYDESTDIR)? Maybe it is possible to put this DESTDIR=$MYDESTDIR in the generated Makefiles somehow... -- Regards, Tomasz Grobelny ___ 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] DESTDIR behaviour with different variable name
On Mon, Apr 11, 2011 at 8:54 AM, Tomasz Grobelny tom...@grobelny.oswiecenia.net wrote: Ok, but is there a way to achieve the same effect so that the user can type just make install and not know anything about DESTDIR environment variable (provided he knows about MYDESTDIR)? Maybe it is possible to put this DESTDIR=$MYDESTDIR in the generated Makefiles somehow... If I understand your use case right (which I might not as you haven't described what you're trying to do, just how you're trying to do it), maybe you can just override CMAKE_INSTALL_PREFIX. If you go this route, check the archives because of the whole _INITIALIZED_TO_DEFAULT aspect of that particular cache variable. tyler ___ 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] DESTDIR behaviour with different variable name
On Mon, 11 Apr 2011 09:01:09 -0700, Tyler ty...@cryptio.net wrote: On Mon, Apr 11, 2011 at 8:54 AM, Tomasz Grobelny tom...@grobelny.oswiecenia.net wrote: Ok, but is there a way to achieve the same effect so that the user can type just make install and not know anything about DESTDIR environment variable (provided he knows about MYDESTDIR)? Maybe it is possible to put this DESTDIR=$MYDESTDIR in the generated Makefiles somehow... If I understand your use case right (which I might not as you haven't described what you're trying to do, just how you're trying to do it), maybe you can just override CMAKE_INSTALL_PREFIX. If you go this route, check the archives because of the whole _INITIALIZED_TO_DEFAULT aspect of that particular cache variable. I already tried playing with CMAKE_INSTALL_PREFIX but the problem was that value of MYDESTDIR was read (and saved to CMAKE_INSTALL_PREFIX) only when configuring first time. That's why DESTDIR mechanism comes closer to what I'm trying to achieve. My use case is something like that: 1. User has some default MYDESTDIR to non writable location. 2. User executes cmake . make install. 3. The installation fails because user has no rights to $MYDESTDIR. 4. User changes MYDESTDIR to another location (writable this time). 5. User executes make install once again and it should succeed. Of course the user could set MYDESTDIR to correct location before building but people often forget that. Now the tricky part is that users are already used to this mechanism (for particular variable name, called MYDESTDIR here). So taking different environment variable instead of DESTDIR would allow me to minimize confusion among users. Otherwise I'll just tell them to set yet another variable (DESTDIR). But I would like to avoid that if at all possible. -- Regards, Tomasz Grobelny ___ 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] embedded path in shared library linked into another shared library
Hi all.. I'm using cmake 2.8.4 on Centos 5.2. I build a libUtility.so and a libSecurity.so which depends on it. The utility library is located in ../../lib/libUtility.so during the build. If I do an ldd on libSecurity.so I can see this relative path for libUtility.so in both the build and install versions of the libSecurity.so library. I would like to remove it, but have had no luck. From the docs it seems that the rpath would be removed if I add SET(CMAKE_SKIP_RPATH TRUE) to the CMakeLists.txt, but there is no change. Thanks! This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed. ___ 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] embedded path in shared library linked into another shared library
2011/4/11 David Aiken david.ai...@cis-vancouver.com: Hi all.. I’m using cmake 2.8.4 on Centos 5.2. I build a libUtility.so and a libSecurity.so which depends on it. The utility library is located in “../../lib/libUtility.so” during the build. If I do an ldd on libSecurity.so I can see this relative path for libUtility.so in both the build and install versions of the libSecurity.so library. I would like to remove it, but have had no luck. From the docs it seems that the rpath would be removed if I add “SET(CMAKE_SKIP_RPATH TRUE)” to the CMakeLists.txt, but there is no change. As far as I understand this http://www.cmake.org/Wiki/CMake_RPATH_handling it should work with CMAKE_SKIP_RPATH set to TRUE did you try using a fresh build tree? You could try with: SET(CMAKE_SKIP_BUILD_RPATH TRUE) SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) SET(CMAKE_INSTALL_RPATH ) -- 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
[CMake] Problems with using libraries that supercede system libraries
I'm pretty new to cmake and I'm trying to port an (early) project with
gtkmm-3.0. The project builds fine with my makefiles, so I know I don't
have errors in the code. I'm running ubuntu lucid so I don't want to
install gtkmm-3.0 (and it's dozen dependencies) in the system locations
(/usr, /usr/local) because when I do that the rest of gnome get's messed
up. So, I have them installed in some development directories:
$HOME/Codes/c/gnome/build
$HOME/Codes/cpp/gnome/build
(The first is for gtk,glib,pango,atk,cairo the second for
gtkmm,glibmm,pangomm,atkmm,cairomm). I'm using Tronic's
LibFindMacros.cmake (and others) from http://zi.fi/cmake/Modules/,
recommended from the wiki:
http://www.itk.org/Wiki/CMake:How_To_Find_Libraries
I've updated the macros to look for the correct versions (i.e. gtk-3.0
instead of 2.4... etc). Before running cmake I export those two paths
above in PKG_CONFIG_PATH. When I run cmake I get the following warning:
Begin paste:
CMake Warning at src/designer/CMakeLists.txt:8 (add_executable):
Cannot generate a safe runtime search path for target designer because
files in some directories may conflict with libraries in implicit
directories:
runtime library [libgdk_pixbuf-2.0.so.0] in /usr/lib may be hidden
by files in:
/home/josh/Codes/c/gnome/build/lib
runtime library [libpango-1.0.so.0] in /usr/lib may be hidden by
files in:
/home/josh/Codes/c/gnome/build/lib
runtime library [libgio-2.0.so.0] in /usr/lib may be hidden by files
in:
/home/josh/Codes/c/gnome/build/lib
runtime library [libglib-2.0.so.0] in /usr/lib may be hidden by
files in:
/home/josh/Codes/c/gnome/build/lib
runtime library [libcairo.so.2] in /usr/lib may be hidden by files
in:
/home/josh/Codes/c/gnome/build/lib
runtime library [libatk-1.0.so.0] in /usr/lib may be hidden by files
in:
/home/josh/Codes/c/gnome/build/lib
runtime library [libgobject-2.0.so.0] in /usr/lib may be hidden by
files in:
/home/josh/Codes/c/gnome/build/lib
runtime library [libglibmm-2.4.so.1] in /usr/lib may be hidden by
files in:
/home/josh/Codes/c/gnome/build/lib
/home/josh/Codes/cpp/gnome/build/lib
runtime library [libgiomm-2.4.so.1] in /usr/lib may be hidden by
files in:
/home/josh/Codes/c/gnome/build/lib
/home/josh/Codes/cpp/gnome/build/lib
runtime library [libpangomm-1.4.so.1] in /usr/lib may be hidden by
files in:
/home/josh/Codes/cpp/gnome/build/lib
runtime library [libcairomm-1.0.so.1] in /usr/lib may be hidden by
files in:
/home/josh/Codes/cpp/gnome/build/lib
runtime library [libatkmm-1.6.so.1] in /usr/lib may be hidden by
files in:
/home/josh/Codes/cpp/gnome/build/lib
Some of these libraries may not be found correctly.
end paste
At first I ignored the warning, because I actually want to link with the
newer versions in /home/josh/Codes... but when I run ccmake to view the
cache, the location of the libraries and includes for these components
is listed as /usr/lib, /usr/include... When I try to run make, several
of the header files can't be found and when running make with VERBOSE=1,
the compile command is using the includes from /usr.
my CMakeLists.txt file looks like this:
begin paste:
---
find_package(GTKmm REQUIRED)
link_directories( ${GTKmm_LIBRARY_DIRS} )
include_directories( ${GTKmm_INCLUDE_DIRS} )
add_executable(designer
main.cpp
CBlockCanvas.cpp
CBlockView.cpp
CMainFrame.cpp
CPortView.cpp
CStateGraph.cpp
CStateNodes.cpp )
target_link_libraries(designer ${GTKmm_LIBRARIES})
---
I'm quite sure that PKG_CONFIG_PATH is set correctly, because the cmake
cache has actually found gtkmm-3.0 in /home/josh/Codes. The cmake cache
has the following libraries found in /usr:
atk
atkmm
cairo
cairomm
gdk-pixbuf
gio
giomm
glib
glibmm
pango
pangomm
and the following in /home/josh
gdk
gdkmm
gtk
gtkmm
Note that gtk(mm) and gdk(mm) are the only libraries whose major version
differs from the system's major versions. In otherwords, cmake seems to
be using /home/josh/Codes when it cant find it in /usr... but using the
ones in /usr/ even if it finds them in /home/josh/Codes. What is further
confusing me, is that the versions found by tronics scripts seem to be
the correct ones. For instance, I get the following output from cmake:
begin paste:
--
-- found pango, version 1.28.3
-- found glib-2.0, version 2.28.3
-- found gio-2.0, version 2.28.3
-- found cairo, version 1.10.2
-- found atk, version 1.33.6
-- found glibmm-2.4, version 2.27.96
-- found giomm-2.4, version 2.27.96
-- found cairomm-1.0, version 1.9.8
Re: [CMake] Problems with using libraries that supercede system libraries
On Monday 11 April 2011, cheshirekow wrote:
I'm pretty new to cmake and I'm trying to port an (early) project with
gtkmm-3.0. The project builds fine with my makefiles, so I know I don't
have errors in the code. I'm running ubuntu lucid so I don't want to
install gtkmm-3.0 (and it's dozen dependencies) in the system locations
(/usr, /usr/local) because when I do that the rest of gnome get's messed
up. So, I have them installed in some development directories:
$HOME/Codes/c/gnome/build
$HOME/Codes/cpp/gnome/build
(The first is for gtk,glib,pango,atk,cairo the second for
gtkmm,glibmm,pangomm,atkmm,cairomm). I'm using Tronic's
LibFindMacros.cmake (and others) from http://zi.fi/cmake/Modules/,
recommended from the wiki:
http://www.itk.org/Wiki/CMake:How_To_Find_Libraries
I've updated the macros to look for the correct versions (i.e. gtk-3.0
instead of 2.4... etc). Before running cmake I export those two paths
above in PKG_CONFIG_PATH. When I run cmake I get the following warning:
You should set CMAKE_PREFIX_PATH instead of relying on pkgconfig. Then you can
be sure that cmake will figure out the stuff in a way that it works (i.e.
libraries with full paths).
Begin paste:
CMake Warning at src/designer/CMakeLists.txt:8 (add_executable):
Cannot generate a safe runtime search path for target designer because
files in some directories may conflict with libraries in implicit
directories:
runtime library [libgdk_pixbuf-2.0.so.0] in /usr/lib may be hidden
by files in:
/home/josh/Codes/c/gnome/build/lib
runtime library [libpango-1.0.so.0] in /usr/lib may be hidden by
files in:
/home/josh/Codes/c/gnome/build/lib
runtime library [libgio-2.0.so.0] in /usr/lib may be hidden by files
in:
/home/josh/Codes/c/gnome/build/lib
runtime library [libglib-2.0.so.0] in /usr/lib may be hidden by
files in:
/home/josh/Codes/c/gnome/build/lib
runtime library [libcairo.so.2] in /usr/lib may be hidden by files
in:
/home/josh/Codes/c/gnome/build/lib
runtime library [libatk-1.0.so.0] in /usr/lib may be hidden by files
in:
/home/josh/Codes/c/gnome/build/lib
runtime library [libgobject-2.0.so.0] in /usr/lib may be hidden by
files in:
/home/josh/Codes/c/gnome/build/lib
runtime library [libglibmm-2.4.so.1] in /usr/lib may be hidden by
files in:
/home/josh/Codes/c/gnome/build/lib
/home/josh/Codes/cpp/gnome/build/lib
runtime library [libgiomm-2.4.so.1] in /usr/lib may be hidden by
files in:
/home/josh/Codes/c/gnome/build/lib
/home/josh/Codes/cpp/gnome/build/lib
runtime library [libpangomm-1.4.so.1] in /usr/lib may be hidden by
files in:
/home/josh/Codes/cpp/gnome/build/lib
runtime library [libcairomm-1.0.so.1] in /usr/lib may be hidden by
files in:
/home/josh/Codes/cpp/gnome/build/lib
runtime library [libatkmm-1.6.so.1] in /usr/lib may be hidden by
files in:
/home/josh/Codes/cpp/gnome/build/lib
Some of these libraries may not be found correctly.
end paste
At first I ignored the warning, because I actually want to link with the
newer versions in /home/josh/Codes... but when I run ccmake to view the
cache, the location of the libraries and includes for these components
is listed as /usr/lib, /usr/include... When I try to run make, several
of the header files can't be found and when running make with VERBOSE=1,
the compile command is using the includes from /usr.
my CMakeLists.txt file looks like this:
begin paste:
---
find_package(GTKmm REQUIRED)
link_directories( ${GTKmm_LIBRARY_DIRS} )
You should not need to call link_directories()...
include_directories( ${GTKmm_INCLUDE_DIRS} )
add_executable(designer
main.cpp
CBlockCanvas.cpp
CBlockView.cpp
CMainFrame.cpp
CPortView.cpp
CStateGraph.cpp
CStateNodes.cpp )
target_link_libraries(designer ${GTKmm_LIBRARIES})
... instead ${GTKmm_LIBRARIES} should be a list of libraries with full path.
Is that the case ?
What does
message(STATUS gtkmm: ${GTKmm_LIBRARIES}) give ?
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] Problems with using libraries that supercede system libraries
You should set CMAKE_PREFIX_PATH instead of relying on pkgconfig. Then you
can
be sure that cmake will figure out the stuff in a way that it works (i.e.
libraries with full paths).
That worked like a charm. I'm glad there turned out to be a simple
solution.
link_directories( ${GTKmm_LIBRARY_DIRS} )
You should not need to call link_directories()...
Removed, thanks for the tip.
... instead ${GTKmm_LIBRARIES} should be a list of libraries with full path.
Is that the case ?
What does
message(STATUS gtkmm: ${GTKmm_LIBRARIES}) give ?
Prior to exporting CMAKE_PREFIX_PATH, it listed full paths to the
libraries and they were /usr/... paths. After setting CMAKE_PREFIX_PATH,
they're all /home/josh/Codes/...
Thanks for the help!
Josh
___
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] How do folks work with rpath on OS X using cmake?
Scenario: A library libA.dylib is found somewhere in the building of executable B. Doing the typical link, otool -L shows that B references: libA.dylib or possibly /A/prefix/lib/libA.dylib. I want B to run from either the build directory or the installation directory, which I want to be portable. A possible solution is to have libA.dylib encoded into B as: @rpath/libA.dylib and then to put @loader_path/ and /A/installdir/lib into the rpath of B, and finally to install libA.dylib alongside B. What is the best way to get this done using CMake? What other approaches are there to this basic problem? Thx.John Cary ___ 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] DESTDIR behaviour with different variable name
On 04/11/2011 10:42 PM, Tomasz Grobelny wrote:
On Monday 11 April 2011 21:55:48 Alexander Neundorf wrote:
On Monday 11 April 2011, Tomasz Grobelny wrote:
On Mon, 11 Apr 2011 09:01:09 -0700, Tyler ty...@cryptio.net wrote:
On Mon, Apr 11, 2011 at 8:54 AM, Tomasz Grobelny
tom...@grobelny.oswiecenia.net wrote:
Ok, but is there a way to achieve the same effect so that the user can
type just make install and not know anything about DESTDIR
environment
variable (provided he knows about MYDESTDIR)? Maybe it is possible to
put this DESTDIR=$MYDESTDIR in the generated Makefiles somehow...
If I understand your use case right (which I might not as you haven't
described what you're trying to do, just how you're trying to do it),
maybe you can just override CMAKE_INSTALL_PREFIX.
If you go this route, check the archives because of the whole
_INITIALIZED_TO_DEFAULT aspect of that particular cache variable.
I already tried playing with CMAKE_INSTALL_PREFIX but the problem was
that value of MYDESTDIR was read (and saved to CMAKE_INSTALL_PREFIX)
only when configuring first time. That's why DESTDIR mechanism comes
closer to what I'm trying to achieve. My use case is something like
that:
1. User has some default MYDESTDIR to non writable location.
2. User executes cmake . make install.
3. The installation fails because user has no rights to $MYDESTDIR.
4. User changes MYDESTDIR to another location (writable this time).
5. User executes make install once again and it should succeed.
Of course the user could set MYDESTDIR to correct location before
building but people often forget that. Now the tricky part is that users
are already used to this mechanism (for particular variable name, called
MYDESTDIR here). So taking different environment variable instead of
DESTDIR would allow me to minimize confusion among users. Otherwise I'll
just tell them to set yet another variable (DESTDIR). But I would like
to avoid that if at all possible.
DESTDIR has a different purpose.
Installing to DESTDIR does not necessarily lead to a working and correct
installation, mainly when paths are involved, like e.g. RPATH settings.
Assuming that CMAKE_INSTALL_PREFIX would be /opt/foo, your executable might
get /opt/foo/lib as RPATH, also when installed to $DESTDIR/opt/foo.
So they will not have a correct RPATH.
You really should set CMAKE_INSTALL_PREFIX.
I'd like to. But CMAKE_INSTALL_PREFIX does not get recomputed when I change
MYDESTDIR and try to do make install again. Or at least I don't know how to
make it behave this way.
Besides, I don't use RPATH (at least not explicitely, hopefully cmake is not
doing anything nasty behind the scenes).
But some day, you might want to use RPATH features as they are very
convenient in certain situations, or you might want to incorporate
the installation prefix or derivatives like CMAKE_INSTALL_PREFIX/lib
/${PROJECT_NAME} in your binaries which can be quite convenient, too.
Moreover, you can hardly prevent your project's users to use RPATH on
their own, see the CMAKE_INSTALL_RPATH/CMAKE_BUILD_WITH_INSTALL_RPATH
variables, e.g. In this regard, using the DESTDIR Makefile/environment
variable bears the risk of subtle failures and isn't worth the effort,
IMO. Thus, you should take Alex's warning absolutely seriously, or in
other words: Changing the installation prefix does invalidate your
already built targets, so you do need to reconfigure and rebuild.
Anyway, see [1] for a chance to add DESTDIR=$MYDESTDIR to the
generated Makefiles, provided that you are using GNU Make, but
even this won't work as expected since DESTDIR is hard-coded
in CMake, AFAIK, and due to other reasons.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg34344.html
___
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] embedded path in shared library linked into another shared library
On 04/11/2011 11:10 PM, David Aiken wrote:
That didn't work for me.. I've got it simplified down to:
SET(CMAKE_SKIP_RPATH TRUE)
and in the CMakeCache.txt I see:
CMAKE_SKIP_RPATH:BOOL=NO
That's not surprising as your SET() command doesn't write to the cache.
It's the CMAKE_SKIP_RPATH variable's value in the current scope which
is - should be - crucial for dropping the RPATH settings, AFAIK.
and further down:
CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1
I'm using the codeblocks unix makefile target. The rpath is present in both
the build and install shared library.
With the UnixMakefile generator, I can see the following CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(RPATH C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(CMAKE_SKIP_RPATH TRUE)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f SHARED f.c)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main f)
produce the following command line to link:
.../gcc CMakeFiles/main.dir/main.c.o -o main -rdynamic libf.so
I.e., no RPATH for the executable.
Does the above-noted CMakeLists.txt actually produce different results
w.r.t. the RPATHs when using the CodeBlocksUnixMakefiles generator?
Regards,
Michael
-Original Message-
From: Eric Noulard [mailto:eric.noul...@gmail.com]
Sent: Monday, April 11, 2011 12:29 PM
To: David Aiken
Cc: cmake@cmake.org
Subject: Re: [CMake] embedded path in shared library linked into another
shared library
2011/4/11 David Aiken david.ai...@cis-vancouver.com:
Hi all..
I'm using cmake 2.8.4 on Centos 5.2. I build a libUtility.so and a
libSecurity.so which depends on it. The utility library is located in
../../lib/libUtility.so during the build. If I do an ldd on libSecurity.so
I can see this relative path for libUtility.so in both the build and install
versions of the libSecurity.so library. I would like to remove it, but have
had no luck. From the docs it seems that the rpath would be removed if I add
SET(CMAKE_SKIP_RPATH TRUE) to the CMakeLists.txt, but there is no change.
As far as I understand this
http://www.cmake.org/Wiki/CMake_RPATH_handling
it should work with CMAKE_SKIP_RPATH set to TRUE
did you try using a fresh build tree?
You could try with:
SET(CMAKE_SKIP_BUILD_RPATH TRUE)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(CMAKE_INSTALL_RPATH )
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
This e-mail and any attachments are intended only for use by the addressee(s)
named herein and may contain confidential information. If you are not the
intended recipient of this e-mail, you are hereby notified any dissemination,
distribution or copying of this email and any attachments is strictly
prohibited. If you receive this email in error, please immediately notify the
sender by return email and permanently delete the original, any copy and any
printout thereof. The integrity and security of e-mail cannot be guaranteed.
___
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, master, updated. v2.8.4-324-g2adb7d3
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, master has been updated via 2adb7d36f249f1392293eb2d4f7b6ea51a8e882e (commit) from a72c0a2004f488e47e71b4f9641e9a74c154adfb (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=2adb7d36f249f1392293eb2d4f7b6ea51a8e882e commit 2adb7d36f249f1392293eb2d4f7b6ea51a8e882e Author: KWSys Robot kwro...@kitware.com AuthorDate: Tue Apr 12 00:01:04 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Tue Apr 12 00:13:01 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 4a0626b..cae4bbd 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 04) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 11) +SET(KWSYS_DATE_STAMP_DAY 12) --- 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
