ITK MacPorts Package Maintainers
MacPorts
For general information about MacPorts, see:
http://www.macports.org/ http://trac.macports.org/wiki/InstallingMacPorts
In general, the best way to contact a port maintainer is to file a trac ticket at http://trac.macports.org/. For the InsightToolkit ports, you can contact me, Darren Weber: dweber__AT__macports.org
You can learn the specifics about MacPorts from:
a) $ man port
b) http://guide.macports.org/chunked/
For a port installed, to find out where everything is, use
$ port contents InsightToolkit
Also, if there is a file installed, the port that installed it can be identified by using
$ port provides ${fullFilePath}
$ port provides /opt/local/bin/bash
/opt/local/bin/bash is provided by: bash
MacPorts for InsightToolkit
The MacPorts for InsightToolkit (ITK) are available at several recent release versions (3.12.0, 3.14.0, and 3.16.0 at Sep 2009). If a prior release is required, that should be possible to create. The port name 'InsightToolkit' should be maintained at the latest release version. Prior releases should be available as 'InsightToolkit${ver}' where the ${ver} is a 3 character string that includes major and minor release numbers. All versions of these ports can co-exist with any other version. All the ports have version specific installation paths (and some of the binaries are renamed with version specific strings appended). However, there are some symlinks for library and executable 'basenames' that should point to the "most recent" version-specific files. To get a list of all the available ports try:
port search InsightToolkit
MacPorts has a feature called 'variants' to allow custom installations and default options. See
port variants InsightToolkit
The default variants select the documentation, shared libs, and wrappers for tcl, java, and python2.5 (as of 2009; for details use 'port cat InsightToolkit' to view the source code in the Portfile).
The build and install process are tested, but the functionality is not extensively tested. If there are problems with the build and installation process, that could be an InsightToolkit bug (maybe a platform specific build error) or a MacPorts bug (submit a report at http://trac.macports.org/). If there are functional bugs after the installation, that's probably an upstream issue to fix in the toolkit.
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).
How-To Install and Upgrade
Before installing new ports, it's highly recommended to perform a general update and upgrade on the ports system, like this:
sudo port selfupdate sudo port upgrade outdated
For a new installation of InsightToolkit, at the latest release available in MacPorts, the terminal command is simply:
sudo port install InsightToolkit
It's recommended to run the installation overnight, because 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 the -d flag:
sudo port -d install InsightToolkit
The -d flag is used for 'debug' information, but also serves as a useful progress meter for the installation process.
For an upgrade to a new release, try this:
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 uninstall InsightToolkit sudo port clean --all InsightToolkit sudo port install InsightToolkit
During port testing, all the examples and the tests were built and installed, which required enabling a couple of variants like this:
sudo port install InsightToolkit +examples +testing
The install paths for the documentation etc. are printed by:
port variants InsightToolkit
To get a full listing of all the files provided, run this after installation:
port contents InsightToolkit
InsightToolkit (@3.16.0)
At the time of this writing, MacPorts contains the latest update of InsightToolkit (@3.16.0). This release should co-exist with prior releases, now called InsightToolkit3XY (see examples below). The prior releases should install along with an installation of InsightToolkit (at the latest release). In testing of an upgrade process, it was necessary to first uninstall InsightToolkit, then upgrade to the new version of InsightToolkit, and finally install the prior version specific port as InsightToolkit${ver}. For example, that process looked like this:
sudo uninstall InsightToolkit sudo port install InsightToolkit sudo port install InsightToolkit314
After some testing and modifications to the ports, the process may be easier. It should be possible to shorten the above to this:
sudo port upgrade InsightToolkit sudo port install InsightToolkit314
InsightToolkit (@3.14.0)
The MacPorts port for InsightToolkit (ITK) is also available at release 3.14.0. This port is available as InsightToolkit314. To install the port, run the following:
sudo port install InsightToolkit314
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'. All the build and install configurations are coded in the Portfile. See the svn browser at:
http://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile http://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit312/Portfile
Those Portfiles are in the subversion development tree and they make their way into a release that is synced to your MacPorts installation:
/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
You can also view properties and content of ports using:
port info InsightToolkit port variants InsightToolkit port cat InsightToolkit
There is a man page on port for all the details on how to use it.
If you want to edit and install your own custom Portfiles, you can follow these instructions:
http://guide.macports.org/#development.local-repositories
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
Development of Insight with MacPorts
The point of this is that all the library dependencies *should* be configured to link against other open-source tools provided by MacPorts (some libraries may be provided by Apple or another site-specific installation). To see the dependencies, use:
$ port deps InsightToolkit InsightToolkit has build dependencies on: cmake gmake gawk bison InsightToolkit has library dependencies on: xorg-libs ossp-uuid guile tcl python25
So, if you want to develop ITK using links against ports provided by MacPorts, that might be done. I suggest you should first learn how to create a local repository (http://guide.macports.org/#development.local-repositories). Once you have your own local repository configured (about 10-20 mins), you should copy the current Portfile for InsightToolkit so that you can modify it (find that file using `port file InsightToolkit`).
The MacPorts installation uses several phases (http://guide.macports.org/#reference.phases) and a developer can stop after the build phase (see `man port` for all the developer targets). At that point, you have a complete source tree and a separate build tree (with no tweaks to the Portfile, you get a release version of ITK, see `port info InsightToolkit`). So you could try this:
sudo port build InsightToolkit ls /opt/local/var/macports/build/
Then you might try to develop directly in the MacPorts build tree, somewhere under /opt/local/var/macports/build/. If your tempted to copy the InsightToolkit tree somewhere else to develop with it, there are some rpath issues to contend with. One problem with moving the build tree somewhere else is that the OSX convention is to use rpath links, so the build tree has a lot of specific links within the build tree (many of these are reset during the destroot phase and there are a ton of hacks in the port to get the rpath right after the destroot phase, especially for the wrapping libs).
If you need to check or correct any cmake configuration settings, read and edit your Portfile and test things like this:
sudo port configure InsightToolkit <+YOUR_VARIANTS> cd /opt/local/var/macports/build/*_InsightToolkit/work/InsightTookit-<version>-build sudo cmake -LAH ../InsightTookit-<version> # or you could use ccmake #sudo ccmake ../InsightTookit-<version>
If you develop directly in the MacPorts build tree, just use make directly to rebuild, rather than `port build InsightToolkit`. That is,
sudo port build InsightToolkit <+YOUR_VARIANTS> # edit src files in /opt/local/var/macports/build/*_InsightToolkit/work/InsightTookit-<version>/ cd /opt/local/var/macports/build/*_InsightToolkit/work/InsightTookit-<version>-build # maybe change some cmake settings #sudo ccmake ../InsightTookit-<version> # Then run a rebuild (it should be incremental) sudo make
If you try to use the port build command, it is likely to say the build is complete; to override that you might use a -f flag or you can edit the 'state' file (work/.macports.InsightToolkit.state in the build path) to remove the line that indicates the build is already done. The port command can sometimes clean out a build tree, but that can be disabled with a -k option to keep the working build tree. For instance, if you run all the phases of a full installation, without a -k option, the MacPorts install process will 'clean' away the entire source and build trees (that's the default, but it can be switched off globally in the macports.config file in /opt/local/etc/macports/).
If you need a current cvs source tree, that can be done using a tweak to the MacPorts Portfile in your local repository. Just modify the version definition and the fetch phase (http://guide.macports.org/#reference.phases.fetch.advanced). It can be configured to use cvs (svn) retrieval. The main issue is that most of the Portfile assumes there is a release version and the version string is used throughout the Portfile (to provide for version specific installations), so you might need more tweaks to get it right, depending on how you specify the version string. Bear in mind that version, epoch, and revision strings are used by port to identify the most current release for installation.
OK, so all that seems to be too much work! So, let's assume you want to checkout from cvs and work in a custom development tree (no sudo required), yet you do want to link against MacPorts libraries. A first step is to install all of the dependencies you need using MacPorts. Then read the configure stage of the Portfile (both the main configure setting and any variant modifications you need), to see how all the cmake variables are set to find MacPorts libraries. You might first run a full installation with all the variants that you need, so that the port system can resolve all the required dependencies. This is a great advantage of MacPorts, saving you a ton of work to find, configure, and install all of your own custom site-specific installations for python, mysql, postgresql, boost, mpi, etc. Then use the cmake -LAH tip above to identify all the cmake variable settings and use them for your custom cmake configure process.
BSD-Darwin / OS-X References
It may be helpful to have a few links to relevant topics on OS-X development here.
This is a general reference library for OS-X, http://developer.apple.com/mac/library/navigation/index.html
This is detailed topics on programming with Mach-O (Mach object) files, http://developer.apple.com/Mac/library/documentation/DeveloperTools/Conceptual/MachOTopics/0-Introduction/introduction.html
Acknowledgements
This work involved help from generous developers in the open source community, including folks dwelling @cmake.org @itk.org @vtk.org (Bill Lorensen, Luis Ibanez, David Cole, Gaëtan Lehmann, Sean McBride, Michael Jackson, et al.) and the folks @macports.org (Bryan Blackburn, Jeremy Huddleston, Jeremy Lavergne, Rainer Müller, Toby Peterson, Joshua Root, Frank Schmia, Ryan Schmidt, et al.).
