Re: [CMake] BundleUtilities (was RPATH on Mac)

Hi Do we have something similar to BundleUtilities for Frameworks ? Best Regards Guillaume On Wed, Apr 20, 2011 at 9:48 PM, David Cole wrote: > On Wed, Apr 20, 2011 at 11:38 AM, Michael Jackson > wrote: >> >> ___ >> Mike Jackson          

Re: [CMake] Better handling of library dependencies for CPack

Hi Eric, Thanks for the response. In another email to cmake.org, I sent a DebSourcePPA.cmake file that shows what i'm doing to generate deb source packages. Your script sets CPACK_DEBIAN_PACKAGE_DEPENDS to "Ubuntu-dep", so I was confused how that adds the correct dependencies... what does a user

Re: [CMake] Better handling of library dependencies for CPack

2011/4/22 Rosen Diankov : > Hi Eric, > > Before I start running things, basically the script sets > CPACK_DEBIAN_PACKAGE_DEPENDS right? What does this effect have on > cpack? On CPack generic part none but the CPack Debian generator use it when building the binary debian package and adds the packa

[CMake] cmake and code signing

Am working on CMake based project, using CPack for building installers. On Windows, I'm using NSIS back-end for CPack. I'm working now on a feature request, consisting of signing the application executable itself, as well as installer exectuable, using my company code signing certificate. Signin

Re: [CMake] Release of new Debian Source Package Generator

Hi all, There was a problem with the previous script on certain versions of tar. I'm attaching a new file that fixes it. rosen, 2011/4/22 Rosen Diankov : > Hi all, > > We just finished a new debian source package generator script for cmake: > > https://openrave.svn.sourceforge.net/svnroot/openra

Re: [CMake] Better handling of library dependencies for CPack

Hi Eric, Before I start running things, basically the script sets CPACK_DEBIAN_PACKAGE_DEPENDS right? What does this effect have on cpack? Also, If we're generating debian source packages, i'm not sure if it is a good idea to set DISTRO_CODENAME, DISTRO_RELEASE, AND DISTRO_ID inside the cmake env

Re: [CMake] Better handling of library dependencies for CPack

2011/4/22 Rosen Diankov : > Hi Guys, > > You are right about shlibdeps, but this is not the whole story. > > Debian source packages required "build dependencies" to be > preinstalled before cmake even runs. This tells each distribution what > it needs so that cmake can find it with find_package. Y

Re: [CMake] Dynamic linking doesn't work after install

On Fri, Apr 22, 2011 at 9:57 AM, David Doria wrote: >> I think the CMake page on RPATHs might be what you are looking for. >> >> http://www.cmake.org/Wiki/CMake_RPATH_handling > > Yea I read that, but I didn't really follow/see how to fix this > problem. Surely there is a "just copy the executable

[CMake] Release of new Debian Source Package Generator

Hi all, We just finished a new debian source package generator script for cmake: https://openrave.svn.sourceforge.net/svnroot/openrave/trunk/modules-cmake/DebSourcePPA.cmake This is based on the initial UploadPPA.cmake file ( http://purplekarrot.net/blog/dputCMake.html ) by Daniel Pfeifer, exce

Re: [CMake] Dynamic linking doesn't work after install

> I think the CMake page on RPATHs might be what you are looking for. > > http://www.cmake.org/Wiki/CMake_RPATH_handling > > Marcus > Yea I read that, but I didn't really follow/see how to fix this problem. Surely there is a "just copy the executable" option? David ___

Re: [CMake] Dynamic linking doesn't work after install

On Fri, Apr 22, 2011 at 9:48 AM, David Doria wrote: > I have created an executable like this: > >  add_executable(ImageCompleter ${AppSources}) >  target_link_libraries(ImageCompleter ${LibrariesAlwaysUsed}) > >  INSTALL( TARGETS ImageCompleter >    RUNTIME DESTINATION ${INSTALL_DIR} ) > > When I

[CMake] Dynamic linking doesn't work after install

I have created an executable like this: add_executable(ImageCompleter ${AppSources}) target_link_libraries(ImageCompleter ${LibrariesAlwaysUsed}) INSTALL( TARGETS ImageCompleter RUNTIME DESTINATION ${INSTALL_DIR} ) When I run the one that is created with 'make', it works fine. However,

Re: [CMake] Better handling of library dependencies for CPack

Hi Guys, You are right about shlibdeps, but this is not the whole story. Debian source packages required "build dependencies" to be preinstalled before cmake even runs. This tells each distribution what it needs so that cmake can find it with find_package. Afterwards, it isn't necessary to speci

Re: [CMake] OS X Framework and their name

Hi again, I assume this is kind of tricky seen the number of answer. hehe Just a quick summary of my situation and what I want to achieve : Currently I can produce 'sfml-system.framework' for debug and release configuration. I use something like this : # add the install rule # if Mac OS

Re: [CMake] Better handling of library dependencies for CPack

2011/4/22 Rolf Eike Beer : >> We've recently started generating (debian) packages with CPack and >> discovered that handling library dependencies for particular >> distributions was not as smooth as it can be. The *_DEPENDS string >> just gets copied over to the final package so it puts all the bur

Re: [CMake] Better handling of library dependencies for CPack

2011/4/22 Rosen Diankov : > Hi all, > > We've recently started generating (debian) packages with CPack and > discovered that handling library dependencies for particular > distributions was not as smooth as it can be. The *_DEPENDS string > just gets copied over to the final package so it puts all

Re: [CMake] Better handling of library dependencies for CPack

> We've recently started generating (debian) packages with CPack and > discovered that handling library dependencies for particular > distributions was not as smooth as it can be. The *_DEPENDS string > just gets copied over to the final package so it puts all the burden > on the user side to manag

[CMake] Better handling of library dependencies for CPack

Hi all, We've recently started generating (debian) packages with CPack and discovered that handling library dependencies for particular distributions was not as smooth as it can be. The *_DEPENDS string just gets copied over to the final package so it puts all the burden on the user side to manage