I agree with Ryan, that separate ports provide more clarity for dependency specifications, but I do not understand macports variants very well. For instance, there is a track ticket on VTK with some discussion about this issue, see: http://trac.macports.org/ticket/19000
In that ticket, tgamblin raises the possibility of using the @X.Y.Z syntax to get version specific installs, eg: port install v...@5.2.1 port install v...@5.4.0 Furthermore, it should be possible to do this: port install v...@5.2.1 port build v...@5.4.0 port deactivate v...@5.2.1 port activate v...@5.4.0 ... etc If so, does this automatically resolve @X.Y into the latest Z version available? Also, similarly, does it automatically resolve @X into the latest Y.Z version? In my experience with macports to date, the @ syntax must be very specific to be effective, it doesn't have automatic resolution to the latest version. I know that Debian has some "symbolic" package names that are resolved to the latest version of a package (an auto-update package name). In any case, there are some issues with simultaneous version installations (please see the trac ticket comments for some details). Given some differences of opinion, it would be great to work out a consensus on how best to move forward. This requires broader discussion that a track ticket, as the resolution is not necessarily specific to any particular port, although this discussion has a focus on VTK for example. Any ports that depend on a specific version of vtk should be able to: (a) specify a dependency on a "vtkXY" port name that includes at least an XY version (or use the @X.Y.Z syntax?), and (b) restrict the build and link search paths to the version required. To my knowlege, vtk doesn't provide a utility like /opt/local/lib/postgresql83/bin/pg_config, but cmake does have some macros for searching out include and library paths (this may also apply to ports in the K-desktop, as they have adopted cmake as their build tool). In the cmake search paths, there are several variables that control the search, including: CMAKE_FIND_FRAMEWORK CMAKE_FIND_ROOT_PATH ONLY_CMAKE_FIND_ROOT_PATH NO_CMAKE_SYSTEM_PATH NO_CMAKE_ENVIRONMENT_PATH NO_SYSTEM_ENVIRONMENT_PATH CMAKE_FRAMEWORK_PATH CMAKE_APPBUNDLE_PATH CMAKE_INCLUDE_PATH CMAKE_INCLUDE_DIRECTORIES_BEFORE Given there are relatively few ports that depend on VTK, I've been looking for inspiration from more significant libraries, like postgresql and python. A possible solution is to adopt a model something like postgresql8x, where the installation goes almost entirely into /opt/local/lib/postgresql8x, including /opt/local/lib/postgresql83/bin, for instance. Translating that model to vtk might result in something like: /opt/local/include/vtk-X.Y /opt/local/lib/vtkX.Y These paths are already the defaults, given $prefix = /opt/local, but notice how posgresql83 has something like a bin path within the lib path, eg: /opt/local/lib/vtk-X.Y/bin This would separate any vtk binaries that are version specific, rather than have them clash under /opt/local/bin/. Another possible solution is to adopt a pythonX.Y model, where the version specific installs include a version suffix. In addition, there is the utility python_select to define the 'current' version. In this model, a build that depends on a specific version of VTK might "temporarily" use something like python_select to define the current version for the build. Take care, Darren On Mon, Apr 13, 2009 at 3:06 PM, Ryan Schmidt <ryandes...@macports.org>wrote: > On Apr 13, 2009, at 16:52, css...@mac.com wrote: > > On Monday, April 13, 2009, at 04:49PM, Darren Weber wrote: >> >> This is a thread to discuss naming conventions for VTK in macports. >>> >>> Macports has the following VTK ports (as of 04/13/2009): >>> >>> VTK @4.4.2 (graphics) >>> 3D visualization toolkit >>> >>> vtk5 @5.2.1 (graphics, devel) >>> 3D visualization toolkit >>> >> >> It might be more clear to rename along the lines of: >> >> vtk @5.2.1 >> vtk-devel @5.4 >> vtk4 @4.4.2 >> >> I'm not sure how best we might handle renaming the existing ports to match >> this scheme, but it would follow the scheme of keeping the "port named >> without a version" as the latest, stable release. I also need to fix the >> case-sensitive handling of the directory versus the port name. Any thoughts? >> > > This is difficult since MacPorts does not have a mechanism for renaming > ports. It would be great if we had such a mechanism. > > > Many of these separate packages in Debian and FreeBSD probably equate to >>> 'variants' in a macport. >>> >> >> That's true. MacPorts provides the extra language bindings in variants >> rather than separate ports, unless the demand hasn't been made to enable a >> particular binding either by default or as a variant. >> > > IMHO separate ports are better than variants, since they can be installed > and uninstalled separately, and depended on (in a dependency statement). The > Subversion language bindings are in separate ports, for example. > >
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users