[MacPorts] #19000: vtk 5.4.0

[MacPorts]

#19000: vtk 5.4.0
---------------------------------+------------------------------------------
 Reporter:  dweber@…             |       Owner:  macports-tickets@…                   
     Type:  enhancement          |      Status:  new                                  
 Priority:  Normal               |   Milestone:  Port Enhancements                    
Component:  ports                |     Version:  1.7.0                                
 Keywords:  VTK vtk 5.4          |        Port:  vtk54 vtk5                           
---------------------------------+------------------------------------------

Comment(by dweber@…):

 Replying to [comment:5 tgamblin@…]:
 > I second raimue's comment that we should have one vtk5 port.  Can't we
 make vtk vtk4 and merge vtk 5.4 into vtk5, then call it vtk to clear all
 this up?  If people want the old version when this is released they can
 do:
 >
 > port install vtk @5.2.blah.
 >
 > Also since kitware claims the latest stable release is 5.4.0, I see
 nothing wrong with making 5.4 the head now (especially if people can
 always install the prev version).

 I'm not so certain this is the way to "clear" this up.  I would prefer to
 see major.minor version numbers in every library port, as in vtkXY where X
 are major and Y are minor version numbers.

 Even if we resolve to put VTK-5-4-0 (or whatever the latest stable release
 is) into THE 'vtk' port, what is the convention for the library
 installation paths?  Do we drop all the major.minor indicators?  I would
 hope not.  The macports installation tree should contain the potential for
 many simultaneous version installations, particularly for a library like
 VTK.  I see clear advantages for client ports to be able to specify a
 dependency on a major.minor port version of VTK.  With those major.minor
 version numbers in the port name, it is very easy to specify the
 dependency without having to resort to a port variant or something to get
 the dependency correct.  Note that I'm talking about ports with dynamic
 library dependency on SOME version of the VTK library, I'm not talking
 about a user trying to specify the port during an interactive port install
 process.

 What about a solution where we have MULTIPLE ports with vtkXY (as in
 postgresql83) and just ONE 'symbolic' port that is just 'vtk' and it
 manually or perhaps automatically points to the highest stable release
 number?  So, if you run {{{port install vtk}}} it would tell you that this
 is resolved into {{port install vtkXY}}} to get the latest version.  I see
 this kind of proxy package all over the place in Debian (Ubuntu) and
 perhaps it serves just this kind of purpose of keeping up with the latest
 versions, while also providing clarity about port (package) versions
 within the port (package) name.  In this way, a 'client' port that depends
 on VTK can specify a version specific dependency (as in vtkXY) or the
 latest version (as in just vtk).

 Aside from these port naming issues, I'm having difficulty with getting
 shared libraries installed for vtk through macports.  I can do a shared
 library install directly from source (without macports) and everything
 works fine, including the java, tcl, and python wrapping.  However, once
 the destroot comes into play with macports, all my configure options are
 broken.  I've yet to resolve how to fix this and I'm sort-a stuck in a
 quagmire of trying to understand the best way to do it, either with some
 kind of rpath configuration (or postdestroot hacking with
 install_name_tool) or some environment variable settings for DYLD (without
 any rpath config).  I don't understand frameworks yet, so I've focused
 entirely on static and dynamic builds into /opt/local/include/vtk-5.x and
 /opt/local/lib/vtk-5.x

 Take care, Darren

-- 
Ticket URL: <http://trac.macports.org/ticket/19000#comment:6>
MacPorts <http://www.macports.org/>
Ports system for Mac OS