FYI, these are my current commens in the vtk-devel port (my local repo only at this point), with regard to cmake RPATH config for macports build and install:
# Notes on RPATH settings for the shared dylib build and install: # # CMake book, Appendix A, p 234: "CMAKE_SKIP_BUILD_RPATH: Do not include RPATHs # in the build tree. Normally CMake uses the build tree for the RPATH when # building executables etc. on systems that use RPATH. When the software is # installed the executables etc. are relinked by CMake to have the install # RPATH. If this variable is set to true then the software is always built with # no RPATH." # # CMake book, Appendix B, p. 301: "... SKIP_BUILD_RPATH is a boolean specifying # whether to skip automatic generation of an rpath allowing the target to run # from the build tree. BUILD_WITH_INSTALL_RPATH is a boolean specifying whether # to link the target in the build tree with the INSTALL_RPATH. This takes # precedence over SKIP_BUILD_RPATH and avoids the need for relinking before # installation." # # Using CMAKE_SKIP_BUILD_RPATH:BOOL=OFF, we get all the executables and dylibs # built with the $build.dir in the rpath. For this to work, we must also have # CMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF. After the build, at the destroot # phase, all the installation candidates (which excludes the examples and # testing binaries) have their rpath settings reset to the INSTALL_RPATH (which # should point to $prefix..., not the $destroot location). VTK_USE_RPATH # is required to ensure that rpath is set for all the installed executables and # dylibs. Best, Darren On Wed, Apr 29, 2009 at 2:08 PM, Darren Weber <[email protected]> wrote: > > > On Tue, Apr 28, 2009 at 4:30 AM, Ryan Schmidt <[email protected]>wrote: > >> On Apr 27, 2009, at 19:48, Darren Weber wrote: >> >> On Mon, Apr 27, 2009 at 5:01 PM, Ryan Schmidt wrote: >>> >>> Since this port uses cmake, have you considered using the cmake >>>> portgroup >>>> to simplify it? >>>> >>> >>> No, I didn't know such a portgroup exists and I have no idea how to use a >>> portgroup. >>> >> >> Portgroups are basically include statements, allowing you include a set of >> definitions that are common to a class of ports. There is a section on >> portgroups in the guide. Unfortunately it does not have any general >> explanation of what a portgroup is. It just describes the options available >> in some of the existing portgroups. >> >> http://guide.macports.org/#reference.portgroup >> >> The cmake portgroup is new and not yet documented in the guide, but you >> can read its source code here to see what it does: >> >> http://trac.macports.org/browser/trunk/dports/_resources/port1.0/ >> group/cmake-1.0.tcl >> >> Basically, all ports that use cmake need to do certain similar things, for >> example depend on the cmake port, use cmake in the configure phase, specify >> the prefix using -DCMAKE_INSTALL_PREFIX instead of --prefix, etc.; the cmake >> portgroup exists to simplify such ports. >> > > > Interesting. The vtk-devel will use options to cmake that conflict with > those in this portgroup (for a shared library build), ie: > > configure.args-append \ > -DBUILD_SHARED_LIBS:BOOL=ON \ > -DCMAKE_SKIP_BUILD_RPATH:BOOL=OFF \ > -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF \ > -DCMAKE_INSTALL_RPATH:STRING=${prefix}/lib/${distname} \ > -DVTK_USE_RPATH:BOOL=ON > > After a lot of reading and some testing, this combination of options > appears to be optimal for vtk-5.4. There are some issues when building the > examples and testing binaries, but some post-destroot hacks with > install_name_tool will take care of that (a better solution might be a patch > to the CMakeLists.txt file for the examples and testing installation phase, > which should automatically apply the INSTALL_RPATH). > > Best, Darren > >
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
