[50222] trunk/dports/graphics
Darren Weber
dweber at macports.org
Mon Apr 27 17:48:30 PDT 2009
On Mon, Apr 27, 2009 at 5:01 PM, Ryan Schmidt <ryandesign at macports.org>wrote:
> On Apr 27, 2009, at 18:27, dweber at macports.org wrote:
>
> Revision: 50222
>> http://trac.macports.org/changeset/50222
>> Author: dweber at macports.org
>> Date: 2009-04-27 16:27:01 -0700 (Mon, 27 Apr 2009)
>> Log Message:
>> -----------
>> The default installation with shared libraries appears to work now; still
>> lots of work to be done on wrapping for java, python, tcl, among other
>> things.
>>
>> Added Paths:
>> -----------
>> trunk/dports/graphics/vtk-devel/
>> trunk/dports/graphics/vtk-devel/Portfile
>>
>> Added: trunk/dports/graphics/vtk-devel/Portfile
>> ===================================================================
>> --- trunk/dports/graphics/vtk-devel/Portfile
>> (rev 0)
>> +++ trunk/dports/graphics/vtk-devel/Portfile 2009-04-27 23:27:01 UTC
>> (rev 50222)
>> @@ -0,0 +1,437 @@
>> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>> +# $Id$
>> +
>> +PortSystem 1.0
>> +
>> +name vtk-devel
>> +version 5.4.0
>> +revision 0
>> +
>> +set branch [join [lrange [split ${version} .] 0 1] .]
>> +
>> +categories graphics math science devel
>> +
>> +maintainers dweber openmaintainer
>> +
>> +description 3D visualization toolkit (www.vtk.org)
>> +
>> +long_description \
>> +An open source, freely available software system for computer graphics, \
>> +image processing, and visualization used by thousands of researchers and
>> \
>> +developers around the world. VTK consists of a C++ class library, and \
>> +several interpreted interface layers including Tcl/Tk, Java, and Python.
>> \
>> +default_variants: +examples +testing +tclSys
>> +
>> +homepage http://www.vtk.org/
>> +master_sites http://www.vtk.org/files/release/${branch}<http://www.vtk.org/files/release/$%7Bbranch%7D>
>> +
>> +distname vtk-${branch}
>> +distfiles vtk-${version}.tar.gz \
>> + vtkdata-${version}.tar.gz
>> +
>> +checksums vtk-${version}.tar.gz \
>> + md5 3e7c6d5c37602c935674d580a8dd43c0 \
>> + sha1 a227caf932315d944cf72008d75df90dd4c554e7 \
>> + rmd160 e2140fc35ed974f5fde6b418089554904e197c21 \
>> + vtkdata-${version}.tar.gz \
>> + md5 283d40f3e499b3a6102d86855d2ca20b \
>> + sha1 a710227e7f7f25f481a36d2fa14bda49756bd39d \
>> + ripemd160 160129a0580bd7b70b40d3f7fa61bbd78b586ad8
>> +
>> +platforms darwin
>> +
>> +#depends_build bin:cmake:cmake
>> +depends_build port:cmake \
>> + port:gmake
>> +depends_lib port:readline
>>
>
> 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.
>
>
> +# Using this dummy stage to inspect macport variables (using 'port -d
>> fetch vtk-devel')
>> +#fetch { system "echo ${workbuildpath} && echo ${worksrcpath} && echo
>> ${destroot}" }
>> +
>> +
>> +# Build in a separate directory from the source
>> +set workbuildpath ${workpath}/${distname}-build
>> +post-extract {
>> + system "cd ${workpath}; mv VTK ${distname}; mv VTKData
>> ${distname}-data;"
>> + system "mkdir ${workbuildpath}"
>> +}
>>
>
> You shouldn't use "system" for tasks which can be performed in plain Tcl.
>
> move ${workpath}/VTK ${workpath}/${distname}
> move ${workpath}/VTKData ${workpath}/${distname}-data
> file mkdir ${workbuildpath}
OK, will adopt this change.
+configure {
>> + system "cd ${workbuildpath} && ${configure.env} && cmake
>> ${configure.args} ${worksrcpath}"
>> +}
>>
>
> configure.env is not a command; running it by itself doesn't have any
> effect, as far as I know. If you want those environment variables to have
> effect for the cmake command, you would not separate configure.env from the
> cmake command with "&&".
configure.env settings will be dropped, completely (see your comment below
also).
> However, see below:
>
> +build {
>> + system "cd ${workbuildpath} && gmake"
>> +}
>> +destroot {
>> + system "cd ${workbuildpath} && gmake install DESTDIR=${destroot}"
>> +}
>>
>
> Why override all these phases? Using the cmake portgroup will take care of
> the configure phase for you, and the build and destroot phases are better
> implemented by just setting the relevant .cmd.
>
> build.cmd gmake
> destroot.cmd gmake
>
> Actually you can omit "destroot.cmd gmake" since the default for
> destroot.cmd is the value of build.cmd.
It's possibly pedantic to be explicit about using gmake, but there it is.
The option to set build.cmd occurred to me. However, the default build
location is ${worksrcpath} and I want to use an out-of-source build path,
hence the specification to "cd ${workbuildpath}". The reason is that I hope
to be able to install both static and dynamic libraries from this vtk port
and it might be wise to build out of source into several different build
paths. The current incarnation uses only a dynamic build by default. It
should be possible to add a +static variant that doesn't conflict with the
dynamic build. I expect this will be built into ${workstaticbuildpath}.
I don't see any variable settings for doing out-of-source builds in
macports. So, the overrides may stand as is.
> +# Set the equivalent of ${configure.ldflags} ${configure.cppflags}
>> +# cmake also has variables called:
>> +# CMAKE_LIBRARY_PATH_FLAG => specify -L compiler options
>> +# CMAKE_LINK_LIBRARY_FLAG => specify -l compiler options
>> +configure.env \
>> + LDFLAGS=-L${prefix}/lib \
>> + CXXFLAGS=-I${prefix}/include
>>
>
> MacPorts already sets LDFLAGS, CXXFLAGS and other variables for you.
>
> +# To double-check all the cmake variable settings after the configure
>> +#cd ${workbuildpath}
>> +#sudo cmake -LAH ../vtk-${branch} > ~/cmake_vars.txt
>> +# Similarly, for an interactive configuration with ccmake, try:
>> +#cd ${workbuildpath}
>> +#sudo ccmake ../vtk-${branch}
>> +
>> +configure.args \
>> + -DBUILD_DOCUMENTATION:BOOL=OFF \
>> + -DBUILD_EXAMPLES:BOOL=OFF \
>> + -DBUILD_TESTING:BOOL=OFF \
>> + -DBUILD_SHARED_LIBS:BOOL=OFF \
>> + -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo \
>> + -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
>> + -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
>> + -DCMAKE_INCLUDE_PATH:PATH=${prefix}/include \
>> + -DCMAKE_LIBRARY_PATH:PATH=${prefix}/lib \
>> + -DCMAKE_INSTALL_NAME_DIR:STRING=${prefix}/lib/${distname} \
>> + -DVTK_DATA_ROOT:PATH=${prefix}/share/${distname}-data \
>> + -DVTK_DEBUG_LEAKS:BOOL=ON \
>> + -DVTK_USE_HYBRID:BOOL=ON \
>> + -DVTK_USE_COCOA:BOOL=ON \
>> + -DVTK_USE_CARBON:BOOL=OFF \
>> + -DVTK_USE_X:BOOL=OFF \
>> + -DVTK_USE_GUISUPPORT:BOOL=ON \
>> + -DVTK_USE_INFOVIS:BOOL=ON \
>> + -DVTK_USE_PARALLEL:BOOL=ON \
>> + -DVTK_USE_RENDERING:BOOL=ON \
>> + -DVTK_USE_VIEWS:BOOL=ON \
>> + -DVTK_WRAP_TCL:BOOL=OFF \
>> + -DVTK_WRAP_JAVA:BOOL=OFF \
>> + -DVTK_WRAP_PYTHON:BOOL=OFF
>> +
>> +
>> + #-DVTK_USE_RPATH:BOOL=OFF \
>> + #-DVTK_REQUIRED_EXE_LINKER_FLAGS:STRING=-rpath ${prefix}/lib \
>> + #-DCMAKE_EXE_LINKER_FLAGS:STRING=-rpath ${prefix}/lib \
>> +
>> +
>> +
>> +# PLATFORMS: platform darwin <version>
>> +# Can be used to handle different tasks depending
>> +# on the version of Mac OS X. The version can be:
>> +# 6 for 10.2 Jaguar,
>> +# 7 for 10.3 Panther,
>> +# 8 for 10.4 Tiger, or
>> +# 9 for 10.5 Leopard.
>> +
>> +platform darwin 8 {
>> + # I have not tested this [dweber]
>> + depends_build-append \
>> + port:gcc40
>> + configure.env-append \
>> + CC=/usr/bin/gcc-4.0 \
>> + CXX=/usr/bin/cpp-4.0 \
>> + MACOSX_DEPLOYMENT_TARGET=10.4
>> +}
>>
>
> Why require port gcc40? Is the gcc 4.0.1 Apple provides with Xcode
> insufficient? If so, and a MacPorts gcc is truly required, you should use
> the latest stable version, which is currently gcc44.
>
> MacPorts already sets MACOSX_DEPLOYMENT_TARGET for you.
That platform variant was adapted from vtk5, sounds like it can be dropped
as macports will deal with it automatically.
>
> +#VTK_REQUIRED_OBJCXX_FLAGS "-fobjc-gc"
>> +# When building VTK with Cocoa, in 10.5, Cocoa supports two memory
>> models:
>> +# reference counting and garbage collection. This compiler flag lets it
>> work with both.
>> +platform darwin 9 {
>> + configure.env-append \
>> + MACOSX_DEPLOYMENT_TARGET=10.5
>> + configure.args-append \
>> + VTK_REQUIRED_OBJCXX_FLAGS="-fobjc-gc"
>> +}
>> +
>> +
>> +# ------------------------------------------------------------------
>> +# VARIANTS
>> +#
>> +# variant name [requires variant] [conflicts variant] [description
>> description]
>> +
>> +default_variants \
>> + +cocoa \
>> + +data \
>> + +examples \
>> + +shared
>> +
>> +variant data description {Install the example data [default]} {
>> +}
>> +
>> +
>> +variant doc description {Build the doxygen documentation} {
>> + depends_build-append \
>> + port:doxygen
>> + configure.args-append \
>> + -DBUILD_DOCUMENTATION:BOOL=ON
>> +}
>> +
>> +
>> +variant examples description {Build and install VTK examples [default]} {
>> + configure.args-delete \
>> + -DBUILD_EXAMPLES:BOOL=OFF
>> + configure.args-append \
>> + -DBUILD_EXAMPLES:BOOL=ON
>> +}
>>
>
> Having fewer variants is better, and since you already make +data and
> +examples default variants, why not just incorporate them into the port
> proper and remove the variants?
Simple -- choice. Anyone can select -data or -examples, but only if they
are variants.
>
> I would also prefer that the port have no default variants. If something
> should be in the port by default, make it so; if necessary, offer variants
> to turn the feature off again, e.g. a "no_shared" or a "no_data" variant.
> However think carefully about whether anyone really needs to turn that
> feature off. If not, don't give the option.
Probably a difference of opinion or just a matter of style. Using default
variants allows other ports to get "essential" features without having to
depend on any variant. Users can switch it off with -<variant> and I prefer
to stick with +<variant> or -<variant> rather than introduce double
negatives like +<no_variant>. Furthermore, the variant syntax provides
additional benefits, like description information to 'port variants
<portname>' and the capacity to specify requires and conflicts, with
additional stage processing options within the variant.
>
>
> +variant testing description {Build VTK tests} {
>> + configure.args-delete \
>> + -DBUILD_TESTING:BOOL=OFF
>> + configure.args-append \
>> + -DBUILD_TESTING:BOOL=ON
>> +}
>> +
>> +
>> +variant tclSys conflicts tclMacPorts description {Tcl Wrapper (System
>> Tcl/Tk)} {
>>
>
> Having capital letters in variant names is unusual. Other ports use
> underscore-separated lowercase words. To distinguish between a MacPorts
> library and a system library, I would prefer that the variant that uses the
> MacPorts library have no special suffix, and the variant that uses the
> system library have the _apple suffix.
>
> variant tcl_apple conflicts tcl {...}
> variant tcl conflicts tcl_apple {...}
>
OK, will adopt as specified.
>
> + configure.args-delete \
>> + -DVTK_WRAP_TCL:BOOL=OFF
>> + configure.args-append \
>> + -DVTK_WRAP_TCL:BOOL=ON \
>> + -DTCL_TCLSH:FILEPATH=/usr/bin/tclsh \
>> +
>> -DTCL_INCLUDE_PATH:PATH=/System/Library/Frameworks/Tcl.framework/Headers \
>> + -DTCL_LIBRARY:FILEPATH=/System/Library/Frameworks/tcl.framework \
>> +
>> -DTK_INCLUDE_PATH:PATH=/System/Library/Frameworks/Tk.framework/Headers \
>> + -DTK_LIBRARY:FILEPATH=/System/Library/Frameworks/tk.framework
>> +}
>> +
>> +# This provides a tcl variant that uses the macports tcl installation.
>> (It seems
>> +# vtk 5.2 does not work with tcl8.5 - macports has 8.5, as of Sep 2008).
>> +variant tclMacPorts conflicts tclSys description {Tcl Wrapper (MacPorts
>> Tcl/Tk)} {
>> + depends_lib-append \
>> + port:tcl \
>> + port:tk
>> + configure.args-delete \
>> + -DVTK_WRAP_TCL:BOOL=OFF
>> + configure.args-append \
>> + -DVTK_WRAP_TCL:BOOL=ON \
>> + -DTCL_TCLSH:FILEPATH=${prefix}/bin/tclsh \
>> + -DTCL_INCLUDE_PATH:PATH=${prefix}/include \
>> + -DTCL_LIBRARY:FILEPATH=${prefix}/lib \
>> + -DTK_INCLUDE_PATH:PATH=${prefix}/include \
>> + -DTK_LIBRARY:FILEPATH=${prefix}/lib
>> +}
>> +# /opt/local/lib/tclConfig.sh
>> +# /opt/local/lib/tkConfig.sh
>> +
>> +
>> +variant java description {Java wrapping for VTK} {
>> + configure.args-append \
>> + -DVTK_WRAP_JAVA:BOOL=ON
>> +}
>>
>
> This requires no additional dependency? If so, why not enable this feature
> always and remove the variant?
This part is still in development. It's a variant to notify everyone that
it's an option and to avoid the port failing if it doesn't build for some
reason (as yet unknown).
>
> +variant python requires shared description {Python Wrapping for VTK} {
>> + depends_build-append port:python26
>> + configure.args-delete \
>> + -DVTK_WRAP_PYTHON:BOOL=OFF \
>> + configure.args-append \
>> + -DVTK_WRAP_PYTHON:BOOL=ON \
>> + -DVTK_NO_PYTHON_THREADS:BOOL=OFF \
>> + -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/include/python2.6 \
>> + -DPYTHON_LIBRARY:FILEPATH=${prefix}/lib/libpython2.6.dylib \
>> + -DPYTHON_DEBUG_LIBRARY:FILEPATH=${prefix}/lib/libpython2.6.dylib \
>> + -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/bin/python2.6 \
>> + -DVTK_PYTHON_SETUP_ARGS:STRING="--prefix=${prefix}
>> --root=${destdir}"
>> +}
>>
>
> You may want to call the variant python26 so that you can later offer other
> variants for other versions of python.
>
OK, good tip.
>
>
> +
>> +
>> +# ---------------------------------------------------------
>> +# There is a problem with RPATH config for the shared libs.
>> +# Until this is fixed, it will not be a default variant.
>>
>
> But you have made it a default variant. See above.
That comment is removed now that it works.
>
>
> +variant shared description {Build shared libraries [default]} {
>> + configure.args-delete \
>> + -DBUILD_SHARED_LIBS:BOOL=OFF
>> + configure.args-append \
>> + -DBUILD_SHARED_LIBS:BOOL=ON \
>> + -DCMAKE_SKIP_BUILD_RPATH:BOOL=ON \
>> + -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
>> + -DCMAKE_INSTALL_RPATH:STRING=${prefix}/lib/${distname} \
>> + -DVTK_USE_RPATH:BOOL=ON
>> +}
>> +
>> +# CMAKE_EXE_LINKER_FLAGS:STRING=
>> +
>> +# -DVTK_INSTALL_LIB_DIR:STRING=${prefix}/lib/vtk-5.2
>> +# -DVTK_USE_RPATH=ON \
>> +# -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF \
>> +
>> +# -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
>> +# Cannot use this RPATH setting because the build tree is
>> +# used to bootstrap the build process, eg:
>> +#
>> +#[ 4%] Generating vtkGLSLShaderLibrary.h
>> +#dyld: Library not loaded: "/opt/local/lib/vtk-5.2"/libvtksys.5.2.dylib
>> +# Referenced from:
>> /opt/local/var/macports/build/_Users_dweber_ports_graphics_vtk5/work/VTK/Utilities/MaterialLibrary/../../bin/ProcessShader
>> +# Reason: image not found
>> +
>> +# Might need variants for carbon vs. cocoa. When doing a shared library
>> +# build, must use carbon, not cocoa.
>> +
>> +
>> +variant carbon conflicts {cocoa x11} description {Build with Carbon} {
>>
>
> So we have the choice between carbon, cocoa, and x11, and only 1 can be
> chosen. But you have made cocoa a default variant. You should only make
> cocoa the default variant if x11 or carbon have not already been chosen. See
> any of several ports for examples of how to handle this, such as minivmac or
> pdftk.
I guessed that when the command line specifies +x11, for instance, the
variant conflict statment would automatically override the default +cocoa
variant. So that's not true?
>
>
> + configure.args-delete \
>> + -DVTK_USE_COCOA:BOOL=ON \
>> + -DVTK_USE_CARBON:BOOL=OFF
>> + configure.args-append \
>> + -DVTK_USE_COCOA:BOOL=OFF \
>> + -DVTK_USE_CARBON:BOOL=ON \
>> +}
>> +
>
>
All the variants below are yet to be evaluated and tested. Soo much to do,
so little time. At the very least, the "placeholders" are positioned for
further work.
>
>> +
>> +variant cocoa conflicts {carbon x11} description {Build with Cocoa
>> [Default]} {
>> +}
>> +
>> +
>> +variant x11 conflicts {cocoa carbon} description {Build with X11} {
>> + #depends_build-append \
>> + port:xorg-libs \
>> + port:xorg-proto
>> + configure.args-delete \
>> + -DVTK_USE_COCOA:BOOL=ON \
>> + -DVTK_USE_X:BOOL=OFF
>> + configure.args-append \
>> + -DVTK_USE_COCOA:BOOL=OFF \
>> + -DVTK_USE_X:BOOL=ON \
>> + -DOPENGL_gl_LIBRARY:FILEPATH=${x11prefix}/lib/libGL.dylib \
>> + -DOPENGL_glu_LIBRARY:FILEPATH=${x11prefix}/lib/libGLU.dylib \
>> + -DOPENGL_INCLUDE_DIR:PATH=${x11prefix}/include \
>> + -DVTK_GLEXT_FILE:FILEPATH=${x11prefix}/include/GL/glext.h \
>> + -DVTK_GLXEXT_FILE:FILEPATH=${x11prefix}/include/GL/glxext.h
>> + -DVTK_OPENGL_HAS_OSMESA:BOOL=OFF
>> +}
>>
>
> You're using items from ${x11prefix} but we now have X11 in ${prefix}. The
> mesa port provides libGL.dylib and so forth. As I see you realize below. We
> have had the convention of the +x11 variant using the MacPorts x11 and the
> +system_x11 variant using the Apple X11. Though we may remove +system_x11
> soon and no longer offer the option.
Oh, might get around to that someday. Trying to get almost everything to
work with cocoa first. If that fails, will certainly get into this a lot
more and draw on the recent additions to the vtk5 port.
>
>
>
> +# This mesaOpenGL variant may not require the x11 variant, but the
>> +# assumption here is that it's more likely to work with it than without
>> it.
>> +
>> +variant mesaOpenGL requires {x11} description {Use mesa OpenGL} {
>> + depends_build-append \
>> + port:mesa
>> + configure.args-append \
>> + -DOPENGL_INCLUDE_DIR:PATH=${prefix}/include \
>> + -DOPENGL_gl_LIBRARY:FILEPATH=${prefix}/lib/libGL.dylib \
>> + -DOPENGL_glu_LIBRARY:FILEPATH=${prefix}/lib/libGLU.dylib \
>> + -DVTK_GLEXT_FILE:FILEPATH=${prefix}/include/GL/glext.h \
>> + -DVTK_GLXEXT_FILE:FILEPATH=${prefix}/include/GL/glxext.h \
>> + -DVTK_OPENGL_HAS_OSMESA:BOOL=ON
>> +}
>> +
>> +
>> +variant mpi description {Use message passing interface (MPI) for parallel
>> support} {
>> + depends_lib-append \
>> + port:mpich2
>> + configure.args-append \
>> + -DVTK_USE_MPI:BOOL=ON
>> +}
>> +
>> +
>> +variant mysql description {Build the MySQL driver for vtkSQLDatabase} {
>> + depends_build-append \
>> + port:mysql5
>>
>
> Please use path:bin/mysql_config5:mysql5 for any mysql5 dependency, so that
> mysql5-devel would also be able to satisfy it.
Huh? Is there a path: syntax to the depends_build option?
>
>
> + configure.args-append \
>> + -DVTK_USE_MYSQL:BOOL=ON
>> +}
>> +
>> +
>> +variant pgsql description {Build the PostgreSQL driver for
>> vtkSQLDatabase} {
>> + depends_build-append \
>> + port:libpqxx
>> + configure.args-append \
>> + -DVTK_USE_POSTGRES:BOOL=ON
>> +}
>> +
>> +
>> +variant odbc description {Build the ODBC database interface} {
>> + depends_build-append \
>> + port:unixODBC
>> + configure.args-append \
>> + -DVTK_USE_ODBC:BOOL=ON
>> +}
>> +
>> +
>> +# ------------------------------------------------------------------
>> +# POST DESTROOT
>> +
>> +set vtkDocPath ${destroot}${prefix}/share/doc/${distname}
>> +set vtkDataPath ${destroot}${prefix}/share/${distname}-data
>> +
>> +# Define variables used by install_name_tool for
>> +# the shared libary installation RPATH
>> +set libdestStr ${destroot}${prefix}/bin/libvtk
>> +set libinstStr ${prefix}/lib/${distname}/libvtk
>> +
>> +post-destroot {
>> +
>> + # Provide data files
>> + xinstall -d -m 0755 ${vtkDataPath}
>> + system "tar -C ${vtkDataPath} -zxvf
>> ${distpath}/vtkdata-${version}.tar.gz"
>> + system "mv ${vtkDataPath}/VTKData/* ${vtkDataPath}/"
>> + system "rm -rf ${vtkDataPath}/VTKData"
>> +
>> + # Add basic documentation
>> + xinstall -d -m 0755 ${vtkDocPath}
>> + file copy ${worksrcpath}/README.html ${vtkDocPath}
>> + file copy ${worksrcpath}/Copyright.txt ${vtkDocPath}
>> + file copy ${worksrcpath}/Testing.txt ${vtkDocPath}
>> +
>> + # Copy examples to the documentation path
>> + if {[variant_isset examples]} {
>> + file copy ${worksrcpath}/Examples ${vtkDocPath}
>> + }
>> +
>> + # Provide some tests in the documentation path
>> + if {[variant_isset testing]} {
>> + foreach x { \
>> + CommonCxxTests \
>> + FilteringCxxTests \
>> + GenericFilteringCxxTests \
>> + GraphicsCxxTests \
>> + IOCxxTests \
>> + ImagingCxxTests \
>> + RenderingCxxTests \
>> + TestCxxFeatures \
>> + TestInstantiator \
>> + VTKBenchMark \
>> + VolumeRenderingCxxTests \
>> + WidgetsCxxTests } \
>> + {
>> + file copy ${worksrcpath}/bin/$x ${vtkDocPath}/Examples
>> + }
>> + }
>> +
>> + #if {[variant_isset shared]} {
>> + # Must set RPATH on all .dylib for shared variant; the RPATH
>> settings
>> + # in the build are hi-jacked by the DESTDIR set by macports
>> during
>> + # 'make install'. Add some system code here to correct the RPATH
>> + # settings for shared libs? Perhaps add the system code to the
>> shared
>> + # variant only.
>> +
>> + # Use install_name_tool to change the
>> + # RPATH settings for each .dylib file.
>> +
>> + # This doesn't work!
>> + #system "cd ${destroot}${prefix}/bin; install_name_tool -change
>> $libdestStr $libinstStr $*{version}.dylib"
>> + # See
>> + # http://qin.laya.com/tech_coding_help/dylib_linking.html
>> +
>> + #for f in `otool -L libvtkRendering.5.2.0.dylib`; do
>> + # echo $f | grep $libdestStr;
>> + #done
>> +
>> + # otool -L ${dylib} | grep ${libdestStr} | sed s/.dylib.*/.dylib/
>> +
>> + # http://guide.macports.org/chunked/reference.phases.html
>> + # During the destroot phase, macports issues:
>> + # make install DESTDIR=${destroot}
>> + # in ${worksrcpath}.
>> + #}
>> +}
>>
>
> It would be easier to understand the port if you put the parts that are
> specific to a variant inside that variant declaration.
>
> So, instead of what you have:
>
>
> variant examples {
> ...
> }
> variant testing {
> ...
> }
> variant shared {
> ...
> }
> post-destroot {
> ...
> if {[variant_isset examples]} {
> ...
> }
> if {[variant_isset testing]} {
> ...
> }
> if {[variant_isset shared]} {
> ...
> }
> }
>
>
> Do this:
>
>
> variant examples {
> ...
> post-destroot {
> ...
> }
> }
> variant testing {
> ...
> post-destroot {
> ...
> }
> }
> variant shared {
> ...
> post-destroot {
> ...
> }
> }
> post-destroot {
> ...
> }
>
>
Difference of opinion. I find it easier to have it all in the post-destroot
because the variables for the doc and data path are set right before it and
most of the work in post-destroot is clearer when you can see those
variables defined right above it. If all the post-destroot is split up all
over the variants, it's harder to see what the post-destroot is doing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090427/d48fb16e/attachment-0001.html>
More information about the macports-dev
mailing list