#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 tgamblin@…): 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. Can't you do this without versions in the port name, even if they're all listed as "VTK"? e.g. I could do: {{{ port install vtk@5.2.1 port install vtk@5.4.0 }}} VTK already keeps the includes and libraries separate for these ($prefix/include/vtk-X.Y, $prefix/lib/vtk-X.Y, etc), so that shouldn't be a problem, but there are going to be problems with VTKData and VTK's binary utilities (vtkWrapPython, vtkpython, vtkEncodeString, etc), which go under /bin and /share without version-specific subdirectories. Things in these directories will conflict if you try to simultaneously install two versions, and this is going to be a problem even if you have separate names for the ports. On the other hand, I believe you CAN have multiple versions built at once under this scheme. You just can't have them active: {{{ port install vtk@5.2.1 port build vtk@5.4.0 port deactivate vtk@5.2.1 port activate vtk@5.4.0 ... etc }}} 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? I don't have a really strong preference here, but raimue seems to. Also like I said, I don't think this is the problem. I think it's that two VTK installs are going to need entirely separate prefixes to be installed together. raimue? Maybe it would make sense to come up with some patches so that things get installed in a non-conflicting way, but I think this is a big change and a fair amount of work. I would rather focus on getting the thing working an the names consolidated before working on the ability to have concurrent versions. What do you think? 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 I'm not sure I understand what the problem here is -- can't we base things on the vtk5 Portfile, which lets cmake do all the hard work? I've got vtk-5.2 installed and the libraries seem to work just fine. Can you be a little more specific? What doesn't run? -- Ticket URL: <http://trac.macports.org/ticket/19000#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS