On 7/23/08 9:06 AM, "Mike Jackson" <[EMAIL PROTECTED]> wrote:
> What should be happening is that your application should be linked > with libraries that have an "install_name" set to @execuatble_path/../ > Frameworks...." or "@executable_path/../Dylibs/...." or something > along those lines. If your application is linked correctly then a > startup script is NOT needed at all as the application will > inherently "know" where to find the libraries. Agreed, this is the "right way". > CMake has support to set the "install_name" of a compiled library. > Brad King posted this to the list back in October of 2007: > > ========================================== > The default behavior is to make things runnable from the build tree. > You can force it to use your given install_name like this: > > ADD_LIBRARY(foo SHARED foo.c) > SET_TARGET_PROPERTIES(foo PROPERTIES > INSTALL_NAME_DIR @executable_path/../Frameworks > BUILD_WITH_INSTALL_RPATH 1 > ) > > This is documented in the SET_TARGET_PROPERTIES command, though it may > not be clear that BUILD_WITH_INSTALL_RPATH applies to install_name too. I hadn't noticed this property, so thanks for the heads-up. However, I believe there are two distinct requirements that have to be addressed for bundles: 1) The executables and shared libraries you build yourself must be linked correctly so they can locate their dependencies. 2) Any third-party executables and shared libraries that you put in your bundle must be linked correctly (or modified) so they can locate their dependencies (if any). INSTALL_NAME_DIR addresses the first case, but not the second - I assume that that's where the home-grown stuff you mention fits in? Cheers, Tim -- Timothy M. Shead Scalable Analytics & Visualization (1424) Sandia National Laboratories 505-284-0139 _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake