#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