[63983] trunk/dports/graphics/InsightToolkit/Portfile

[Darren Weber]

Right, OK, this is not a lib-dep for InsightToolkit.


Here's my understanding of the dependency.

a) Certainly we have a build-dep on cmake.

b) Any user-software that links to InsightToolkit will also use cmake in the
build process.  The configuration of the user-software will have a
CMakeLists.txt file, with instructions for cmake, which will contain
something like this:

{{{
# Find ITK.
SET (ITK_DIR /opt/local/lib/InsightToolkit-3.16)
FIND_PACKAGE(ITK REQUIRED)
INCLUDE(${ITK_USE_FILE})
}}}

In this case, the ITK_DIR is set explicitly.  This is required for software
that builds against the MacPorts installation of InsightToolkit because it
is a "non-standard" install path (i.e. it is different from a default
/usr/local/ installation).

In the cmake modules, there are many 'macros' to automatically locate
libraries.  Just take a look at {{{ $ ls /opt/local/share/cmake-2.8/Modules/
}}}, where you can see a lot of "Find*.cmake" macros, which have some
assumptions about where libraries are usually installed.

AFAIK, none of those modules are designed to auto-detect libraries in a
MacPorts installation.  The MacPorts installation path does not "fit" into
any of those assumptions, so these modules will fail to find MacPorts
libraries.  That may be a good thing or not, depending on how you want to
build libraries.  However, one purpose to having cmake installed via
MacPorts may be to facilitate building software against the MacPorts
libraries (no?).

This was true for the FindITK.cmake module in the cmake-2.6 port for
MacPorts.  The cmake-2.8 module is
in /opt/local/share/cmake-2.8/Modules/FindITK.cmake

The purpose of this module is to find an ITKConfig.cmake file and load it's
settings.  In MacPorts, this file is located in /opt/local/lib/
InsightToolkit*/ITKConfig.cmake.  If more than one version of InsightToolkit is
installed, it is important to get the right version of this config file.
 There should be a symlink from /opt/local/lib/InsightToolkit to latest
version-specific installation of InsightToolkit (this symlink is created by
the InsightToolkit port).

HERE'S THE POINT:

At present, the post-destroot phase of InsightToolkit creates a
version-specific cmake module file,
e.g. /opt/local/share/cmake-2.8/Modules/FindITK-3.16.cmake.  With that file
in place, it is possible to use a CMakeLists.txt file like this:

{{{
# Find ITK.
FIND_PACKAGE(ITK-3.16 REQUIRED)
INCLUDE(${ITK_USE_FILE})
}}}

In the event that cmake is upgraded (and the old version removed), without a
rebuild ofInsightToolkit, this instruction in the CMakeLists.txt file will
fail with a warning about setting the ITK_DIR.

Most user software will use this in a CMakeLists.txt file:

{{{
# Find ITK.
FIND_PACKAGE(ITK REQUIRED)
INCLUDE(${ITK_USE_FILE})
}}}

This will instruct cmake to run the FindITK.cmake module.  If a user has ITK
(InsightToolkit) installed anywhere like /usr/local/lib/InsightToolkit, this
module will find that lib and configure the build against it.  If that's
what a user wants, fine.  If a user wants to build against MacPorts libs,
using a MacPorts installation of cmake, they may get surprises.  The cmake
modules will most likely detect libs outside the MacPorts installation.

This might be a contributing problem to a persistent issue we are having
with building the python wrapping for InsightToolkit against the MacPorts
installation of python 2.6 (it's a mystery that the cmake config in the port
is not respected during the configure phase).

SUMMARY:

a) OK, change it back to a build-dep.

b) Take out the custom FindITK-3.16.cmake module in the post-destroot?  Put
this into a separate port, maybe something like InsightToolkit-select?  This
new port could configure the cmake module and the /usr/local/lib/
InsightToolkit symlink to point to a version specific installation.

c) Modify all the cmake modules in the MacPorts install of cmake so they can
find libraries that are installed by MacPorts, with a priority to find the
MacPorts libraries before Apple libs, but after user-installed libs in
/usr/local etc.


On Fri, Feb 19, 2010 at 7:31 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

>
> On Feb 19, 2010, at 19:12, Darren Weber wrote:
>
> > It was a build-time dependency, but I changed it to a lib-dep because
> cmake contains Modules in
> >
> > /opt/local/share/cmake-2.8/Modules/
> >
> > Whenever cmake is upgraded, the path to these modules may change and the
> InsightToolkit should build again to modify some of those module files, like
> FindITK.cmake.  This re-build is very expensive in order to run just the
> post-destroot phase of InsightToolkit, but it's the only way to get those
> module changes (at this time).
> >
> > Perhaps a new port that only modifies the cmake modules for
> InsightToolkit is the way to go?  This new port could have a lib-dep on
> cmake, while InsightToolkit could have a build-dep on it.
>
> But are those modules used by InsightToolkit at runtime? If so, it should
> be a library dep on cmake. If not, it should be a build dep. It doesn't
> really have anything to do with whether updating cmake causes that path to
> change, except that if it does, and if those modules are used by cmake's
> dependents at runtime, then the revision of those dependents must be
> increased to force a rebuild. I didn't see any part of InsightToolkit
> dynamically linking to anything in that directory, using "otool -L", but it
> could be dlopening or reading those files in other ways that I can't check.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20100223/ac327c69/attachment.html>