VTK port naming conventions

[Darren Weber]

Proposed summary:

Where possible, do not use <port><major><minor> (eg: vtk54), rather <port>
should be the latest STABLE version (eg: the port named 'vtk' should contain
5.2.x at the time of this writing).  Any version of a port that is near the
cutting edge must have the -devel suffix on the port name (eg, vtk-devel
should contain 5.4.0 at the time of this writing).   An exception to this
rule is where multiple versions of a port (VERSIONS - not variants) must be
installed due to down-stream dependencies on incompatible versions.  This
usually occurs for older versions than the current stable version.  In this
case, the older versions should adopt the name <port><major><minor> (or at
least <port><major>, depending on the port compatibility policies) and, if
possible, the down-stream ports that depend on it should have revised
dependency specifications (eg, change the dependency from 'vtk' to 'vtkXY')
- unless or until the downstream ports can be updated to be compatible with
the latest releases in their dependency tree.  At the point where a library
like vtk is updated to a new incompatible release (eg, a major version
change, such as 4.x to 5.x), the vtk port becomes the latest stable version
and the prior port becomes at least vtk<major>, if not vtk<major><minor>.
In the event that older stable releases are updated with bug fixes, the
live-check mechanism might be used to detect and upgrade the port (assuming
the bug fixes don't change compatibility).

[Note.  Avoid '.' in the port name, so don't do <port><major>.<minor> in the
port name.]

Conclusion:
vtk becomes vtk4 or vtk44 @4.4.2
vtk5 becomes vtk @5.2.1
vtk54 becomes vtk-devel @5.4.0

[Note.  When vtk-5.4.x becomes at least 5.4.1, it will become 'vtk' and then
vtk-devel will disappear - at least until the next time a -devel is
required, when we get say vtk-5.5.0 or some other change that might be
incompatible with vtk-5.4.x.]

The result of these changes should provide something like (at the time of
writing):

[ me at XXX ~ ]$ port search vtk
vtk44 @4.4.2 (graphics)
    3D visualization toolkit (www.vtk.org)

vtk @5.2.1 (graphics)
    3D visualization toolkit (www.vtk.org)

vtk-devel @5.4.0 (graphics, devel)
    3D visualization toolkit (www.vtk.org)


Note that there has to be some changes in the Portfile to the way the
${name}, etc. variables are handled when there is a change in the version
release.  For example,

name          vtk44
version       4.4.2
revision      0
set branch    [join [lrange [split ${version} .] 0 1] .]
homepage      http://www.vtk.org/
master_sites  http://www.vtk.org/files/release/${branch}
distname      vtk-${branch}
distfiles     vtk-${version}.tar.gz \
              vtkdata-${version}.tar.gz
post-extract {
    system "cd ${workpath}; mv VTK ${distname}; mv VTKData ${distname}-data"
}


In any case, all the vtk ports should assume that more than one version of
the library can be installed and those installations should be separated
into independent locations (hopefully this can be handled with the right
CMAKE variable settings).  For the most part, this already happens in vtk,
although there are some binaries that are not version specific that get
installed into ${prefix}/bin/.

If we have a consensus on this, we might conclude this discussion of the VTK
naming convention.

Take care, Darren


PS, Additional summary notes or issues to be resolved elsewhere:

a) vtk takes a long time to build, so the default variant should provide a
complete installation (wrapping for tcl, python, and java, plus docs,
examples, data, tests, or whatever).  The wrappers for tcl, python, java
should be variants, so too with docs, examples, data, etc., which are
included by default, but thereby making it possible to exclude them with
-<variant> syntax.  There should be some documentation in the
long_description about the variants, to explain the variant compatibility
and the defaults.

b) Additional variants, or separate ports, for substantial combination of
vtk with other ports, like Qt, mysql, postgresql, etc.  During the build for
vtk, there are distinct options to include classes and links to additional
functionality for GUI and database programming (among others).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20090415/9306d3fe/attachment.html>