VTK port naming conventions

[Darren Weber]

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).

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 <ryandesign at macports.org>wrote:

> On Apr 13, 2009, at 16:52, cssdev at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20090414/788752bf/attachment.html>