ITK MacPorts Package Maintainers
MacPorts for InsightToolkit
The MacPorts ports for InsightToolkit (ITK) are available at several recent release versions, 3.12.0 and 3.14.0. If you need any prior release, that should be possible and maybe easy to provide. The default variants select the documentation, shared libs, and wrappers for tcl, java, and python2.5.
For a new installation of InsightToolkit, at the latest release available in MacPorts, all you need is:
sudo port selfupdate sudo port install InsightToolkit
It's recommended that you run the installation overnight. It's a very long build and install process (in testing, there was some random instability with parallel builds, so that was disabled to provide a reliable build and install process). For detailed progress on the build and install, use:
sudo port -d install InsightToolkit
The -d option is used for 'debug' information, but also serves as a useful progress meter for the installation process.
If you need to upgrade to a new release, then try this:
sudo port selfupdate sudo port upgrade InsightToolkit
The default upgrade process can leave some files around on the system from the previous installation. To be sure to get a clean upgrade to a new release, try this:
sudo port selfupdate sudo port uninstall InsightToolkit sudo port clean --all InsightToolkit sudo port install InsightToolkit
You can see the install paths for the documentation etc. by using:
port variants InsightToolkit
To get a full listing of all the files provided, run this after installation:
port contents InsightToolkit
Advice and comments on the ports are welcome, especially if there are additional features that could be enabled. Please consider the ports functional, but also a work in progress. At this time, the ports do not include the InsightApplications (one step at a time; that may be a separate port).
The build and install works, but the functionality has not been extensively tested (not sure how to run all the tests under the MacPorts build and install system). If you discover any problems with the build and installation process, that could be a MacPorts bug, for which you can submit a bug report at http://trac.macports.org/. If you discover functional bugs after the installation, that's probably an upstream issue to fix in the toolkit itself.
For general information about MacPorts, see:
http://www.macports.org/ http://trac.macports.org/wiki/InstallingMacPorts
InsightToolkit (@3.14.0)
At the time of this writing, MacPorts contains the latest update of InsightToolkit (@3.14.0), in a port of the same name.
To best of my knowledge, this new release can co-exist with a prior release, now called InsightToolkit312 (@3.12.0). This prior release was modified so that it will install along with an installation of InsightToolkit (@3.14.0). In my testing of this process, I first had to uninstall InsightToolkit (@3.12.0), then upgrade to InsightToolkit (@3.14.0), and finally install the prior release port, now called InsightToolkit312. That process looked like this:
sudo uninstall InsightToolkit sudo port selfupdate sudo port install InsightToolkit sudo port install InsightToolkit312
After some testing and modifications to the ports, the process may be easier now. If your lucky, you might be able to shorten the above to this:
sudo port selfupdate sudo port upgrade InsightToolkit sudo port install InsightToolkit312
During testing, I also built and installed all the examples and the tests, which looked like this:
sudo port selfupdate sudo port install InsightToolkit +examples +testing
InsightToolkit (@3.12.0)
The MacPorts port for InsightToolkit (ITK) is also available at release 3.12.0. This port is available as InsightToolkit312. To install the port, run the following:
sudo port install InsightToolkit312
Notes on Wrapping
Some port hacks were required to get all the rpath settings right for the Tcl .dylib and python .so libraries in the WrapITK/lib/. Further hacks were required for the itkwish shell script in $prefix/bin/itkwish and the actual binary in WrapITK/bin/itkwish. On my system, at least, the itkwish binary works and the 'import itk' works for python2.5. The wrapper also includes java, but I've not tested it. The port does try to fix library references in the .jnilib files, but this assumes those files can be modified by install_name_tool (actually, I have no idea how to work with .jnilib files, so please enlighten me if you want java wrapping to work, if it's not working already).
It might be possible to get the wrapping working for python2.6, but I encountered some weird results when trying to set the configuration options for the python2.6 framework library in MacPorts. Despite setting specific paths to the python2.6 library in macports, the cmake or WrapITK configuration process automatically redefined the library variables to '-framework Python' and that was automatically resolved to the Apple framework in /Library/... rather than the MacPorts framework in /opt/local/Library/... It may be possible to resolve this using some environment variable settings, but it would be nice to avoid that, if possible, in preference to specific cmake (or WrapITK) configuration settings.
The Portfiles
For the curious, the details of the port are all in the pseudo tcl script called the 'Portfile', see:
http://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile
If you want to use these Portfiles directly, you can follow the guide instructions at:
http://guide.macports.org/#development.local-repositories
All the build and install process is coded in the Portfile, which you can read like a pseudo tcl script. You can see all the details of these ports in these files in the MacPorts rsync:
/opt/local/var/macports/sources/rsync.macports.org/release/ports/graphics/InsightToolkit/Portfile /opt/local/var/macports/sources/rsync.macports.org/release/ports/graphics/InsightToolkit312/Portfile
The svn browser is also available, at:
http://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile http://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit312/Portfile
CMake Issues
Once it's installed, your CMakeLists.txt file(s) may have to set the ITK_DIR to be certain about linking, i.e.:
SET (ITK_DIR /opt/local/lib/InsightToolkit-3.14)
If this port has succeeded in the right modifications to FindITK.cmake etc (see below), then it is possible to use this too to get a version specific link:
FIND_PACKAGE(ITK-3.14 REQUIRED)
Once macports gets a revision to cmake (hopefully soon), the FIND_PACKAGE(ITK REQUIRED) should find and link against a generic /opt/local/lib/InsightToolkit installation, rather than a version specific installation (i.e., the FindITK.cmake module should find a MacPorts installation before it finds any others on the system).
One issue with the port is the non-default installation location to /opt/local/lib/InsightToolkit-3.14/. I made the decision to provide this version specific library path (and /opt/local/include/InsightToolkit-3.14/), so it may be possible to install multiple versions of the library in MacPorts (there may be some bugs to work out for this). The InsightToolkit specifies very tight compatibility versions (e.g., itk 3.14.0 has compatibility only for 3.14.0), so any MacPorts software that builds on it may either require a specific version dependency or it will have to keep up with the current version available in MacPorts. In case any software that is stable for a specific version is included in MacPorts, it should be possible to get a resolution for a version specific dependency. When this port is updated to a new release (say 3.16.0), the current port will move to a new port name, called InsightToolkit314, so it will remain available at that version.
However, this raised a port issue because the cmake macro FindITK.cmake is managed by the cmake port (under /opt/local/share/cmake-2.6/Modules/FindITK.cmake). Rather than hack that file directly (which should happen in a new revision for cmake @ 2.6.4), this port does several things. First it creates a symlink from PREFIX/lib/InsightToolkit to PREFIX/lib/InsightToolkit-3.14 (where PREFIX is /opt/local). It also makes a copy of FindITK.cmake into FindITK-3.14.cmake and modifies the content of the copy to indicate the include and lib paths are PREFIX/lib/InsightToolkit-3.14/ (a revision to the cmake port should do similarly for FindITK.cmake). Furthermore, the PREFIX/lib/InsightToolkit-3.14/ITKConfig.cmake was modified to point to this install path also. I guess it is a bug in cmake that the CMAKE_INSTALL_NAME_DIR:STRING=${prefix}/lib/InsightToolkit-3.14 is not actually used as the install path (it defaults back to ${prefix}/lib/InsightToolkit), or I'm missing another cmake variable setting to control this.
A proposed revision for the MacPorts cmake port is at:
https://svn.macosforge.org/repository/macports/users/dweber/devel/cmake/Portfile
A better solution may be an upstream change in cmake, to code module search paths at compile time to facilitate porting of cmake to various distribution platforms. The examples below use MacPorts only because that's what I'm working with at the moment. The issue applies to any port of cmake on a specific distribution platform (MacPorts, Fink, DebIan, freebsd, ubuntu, redhat, etc.).
The main PREFIX on MacPorts is /opt/local/. This will list all the module files that contain /opt/local for an installation of cmake 2.6 on MacPorts:
$ grep -C3 ".*/opt/local.*" /opt/local/share/cmake-2.6/Modules/*.cmake
Not all the .cmake files contain this prefix. Moreover, even when the /opt/local prefix is in a module search path, it doesn't resolve an issue of path precedence. For example:
/opt/local/share/cmake-2.6/Modules/Findosg_functions.cmake- PATH_SUFFIXES lib64 lib /opt/local/share/cmake-2.6/Modules/Findosg_functions.cmake- PATHS /opt/local/share/cmake-2.6/Modules/Findosg_functions.cmake- /sw # Fink /opt/local/share/cmake-2.6/Modules/Findosg_functions.cmake: /opt/local # DarwinPorts /opt/local/share/cmake-2.6/Modules/Findosg_functions.cmake- /opt/csw # Blastwave /opt/local/share/cmake-2.6/Modules/Findosg_functions.cmake- /opt /opt/local/share/cmake-2.6/Modules/Findosg_functions.cmake- /usr/freeware
Here, the path precedence may favor the main alternative to MacPorts for open-source ports on OSX - Fink. If anyone has both Fink and MacPorts installed, any of their MacPorts cmake builds that require any such module could link against a Fink library because it appears higher in the module path precedence (even when /opt/local is in the module search path). The same argument applies in reverse if the module shuffles around these paths to favor MacPorts over Fink (or some other distribution) in the search path precedence.
I'm not aware of a cmake build-time config variable that allows distros to set a specific module search path. That might be really neat! Maybe something like the following when building cmake:
-D CMAKE_MODULE_PREFIX_PATH:STRING=/opt/local;/usr/local;/usr -D CMAKE_MODULE_INCLUDE_PATH:STRING=/opt/local/include;/usr/local/include;/usr/include -D CMAKE_MODULE_LIBRARY_PATH:STRING=/opt/local/lib;/usr/local/lib;/usr/lib;/usr/lib64
If something like this could be defined, then module .cmake files could use these cmake variables to define their search paths, rather than have them hard-coded in the module files. If these variables are not set explicitly, some common fallback paths must be set.
See this ticket for further details on this issue for MacPorts: http://trac.macports.org/ticket/19781
