Darren Weber wrote:
[]
Gnu libtool has a mechanism to deal with this situation (creating temporary
wrapper scripts for each executable), but if cmake has one, I haven't found
it.
I have a testing build that seems to create paths within the build
tree that are specific to the build, but once they are installed all
the paths are updated to the install path, ie:
It works for me now, too, without using DYLD_FALLBACK_LIBRARY_PATH. I
thought I had tried all other possible combinations without success, but
now I tried the most obvious again, and it did what it was supposed to.
The flags are now
-DBUILD_SHARED_LIBS:BOOL=ON \
-DVTK_INSTALL_LIB_DIR:STRING="/lib/vtk52" \
-DCMAKE_INSTALL_PREFIX:PATH=%p \
-DCMAKE_INSTALL_NAME_DIR:STRING=%p/lib/vtk52 \
-DVTK_USE_RPATH=ON \
-DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF \
-DCMAKE_INSTALL_RPATH:STRING="${CMAKE_INSTALL_NAME_DIR}" \
Maybe the upgrade to cmake-2.6.2_rc4 helped. The nice thing about the
latest cmake version is that it defines a reasonable
compatibility_version now, such as:
otool -L /sw/lib/vtk52-cocoa//libvtkInfovisTCL.5.2.0.dylib
/sw//lib/vtk52-cocoa//libvtkInfovisTCL.5.2.0.dylib:
/sw/lib/vtk52-cocoa/libvtkInfovisTCL.5.2.dylib (compatibility version
5.2.0, current version 5.2.0)
/sw/lib/vtk52-cocoa/libvtkInfovis.5.2.dylib (compatibility version
5.2.0, current version 5.2.0)
/sw/lib/vtk52-cocoa/libvtkWidgetsTCL.5.2.dylib (compatibility version
5.2.0, current version 5.2.0)
etc.
--
Martin
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
