[50222] trunk/dports/graphics

Darren Weber dweber at macports.org
Wed Apr 29 14:10:12 PDT 2009


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 <dweber at macports.org> wrote:

>
>
> On Tue, Apr 28, 2009 at 4:30 AM, Ryan Schmidt <ryandesign at macports.org>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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090429/9384502e/attachment.html>


More information about the macports-dev mailing list