VTK port naming conventions

Tue Apr 14 17:27:39 PDT 2009

On Tue, Apr 14, 2009 at 2:23 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

> This is really more of a development question and not a usage question so
> macports-dev may be a better place to continue this.
>
>
> On Apr 14, 2009, at 12:55, Darren Weber wrote:
>
>  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 vtk at 5.2.1
>> port install vtk at 5.4.0
>> Furthermore, it should be possible to do this:
>> 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
>> 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).
>>
>
> MacPorts does not offer the facility to install a specific version of a
> port. It only lets you install the current version of the port.
>
> "port install vtk at 5.2.1" will not install version 5.2.1; it will install
> whatever version is currently offered by the port. Once a port has been
> updated to a new version, MacPorts no longer has any information about the
> older version of the port.
>
> You can *uninstall*, *deactivate* and *activate* specific versions which
> have already been installed. For example, if you install zlib, and that
> gives you version 1.2.1, and later version 1.2.3 becomes available and you
> "port upgrade zlib" to get it, you now have two versions of zlib installed:
> zlib @1.2.1_0 and zlib @1.2.3_0, with the latter being active. If you wish
> to go back to 1.2.1_0, you can "port deactivate zlib" (which will deactivate
> zlib @1.2.3_0; specifying the version is not necessary here because there is
> only one zlib active) and then "port activate zlib @1.2.1_0". Note this is
> only possible because the old version had already previously been installed.
>
> Instructions for installing an older version of a port directly are in the
> wiki:
>
> http://trac.macports.org/wiki/howto/InstallingOlderPort
>

The conclusion to be drawn from this part of our discussion is that any
ports that depend on a specific version of VTK can specify that version
dependency only if there is a version specific port available (ie, vtkXY).
It is not possible for a port to specify a dependency using the @X.Y.Z
syntax.

The next question is, why would any port require a dependency on a specific
version of VTK?  Furthermore, if it does, to what extent is that port
compatible with future releases of VTK?  So, moving on to the next question
below.

>
>
>
>  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.
>>
>
> The only reason python and postgresql have separate ports for separate
> major versions is because the major versions are incompatible with one
> another. If you have a database that was created with postgresql 8.2, you
> cannot suddenly switch to 8.3; you must perform some database conversion
> which it is not MacPorts' place to do for you. Therefore we must let you
> switch at a time of your choosing and offer both versions. If you compile a
> module for python 2.5, you cannot use that module with python 2.6; it must
> be recompiled. Therefore we offer separate ports for each python port for
> use with each python version.
>
> Is this the case with vtk? If so, multiple ports are best. If not, a single
> port is best, for simplicity.
>
>

I've taken some pain to read through the Apple doc on dynamic libs, see:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLibraries/index.html

It provides some useful tips on how to specify compatibility flags for
dynamic library builds.  That issue is something to take up at the level of
VTK development, rather than porting VTK (although clearly there is a
signficant relationship between the two).  I have to do some more homework
to be clear about this issue and how the VTK build specifies compatibility
(if it does so for OSX).

I have not had enough experience with VTK to know how compatible it is
across minor version releases.  To provide flexibility, I've assumed that
vtkXY should be sufficient to provide the major.minor (X.Y) version
specificity for any port that depends on VTK (ie, I've not considered vtkXYZ
to be necessary).  Certainly vtkX at a minimum to provide the major release
compatibility.

At this point, do we have a consensus that port names should have a version
string in the name?  (We may not agree on the specificity of that version
string - vtkX, vtkXY, vtkXYZ - but it appears the @ syntax is not an
option.)

Any thoughts about additional naming conventions, as used in Debian and
FreeBSD?  That is, should we stick with variants (with some of the issues
that have come up recently in vtk5, see ticket
http://trac.macports.org/ticket/19111). Bear in mind that variants cannot be
specified as dependencies (correct me if that is wrong OR if that will
change in a new release of port).  What about:

libvtk[XYZ] ?  (where [XYZ] is some variant specificity to be decided)

vtk[XYZ]-data ?
vtk[XYZ]-pythonX.Y ?
vtk[XYZ]-qtX ?

etc?

For reference, again, see the Debian distribution, eg:
http://packages.debian.org/search?keywords=vtk
&searchon=names&suite=stable&section=all
A similar story with FreeBSD, see:
http://www.freebsd.org/cgi/ports.cgi?query=vtk&stype=all

Take care, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20090414/7c9b9668/attachment.html>