[MacPorts] #19000: vtk 5.4.0
MacPorts
noreply at macports.org
Tue Apr 14 09:24:01 PDT 2009
#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 at 5.2.1
port install vtk at 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 at 5.2.1
port build vtk at 5.4.0
port deactivate vtk at 5.2.1
port activate vtk at 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
More information about the macports-tickets
mailing list