ITK MacPorts Package Maintainers: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
No edit summary
Line 67: Line 67:
  sudo port selfupdate
  sudo port selfupdate
  sudo port install InsightToolkit +examples +testing
  sudo port install InsightToolkit +examples +testing


== InsightToolkit (@3.12.0) ==
== InsightToolkit (@3.12.0) ==
Line 73: Line 74:


  sudo port install InsightToolkit312
  sudo port install InsightToolkit312


== CMake Issues ==
== CMake Issues ==
Line 78: Line 80:
Once it's installed, your CMakeLists.txt file(s) may have to set the ITK_DIR to be certain about linking, i.e.:
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.12)
  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:
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.12 REQUIRED)
  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).
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.12/.  I made the decision to provide this version specific library path (and /opt/local/include/InsightToolkit-3.12/), 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.12.0 has compatibility only for 3.12.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 3.14.0, the current port will move to a new port name, called InsightToolkit312, so it will remain available at that version.
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
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
/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.12 (where PREFIX is /opt/local).  It also makes a copy of FindITK.cmake into FindITK-3.12.cmake and modifies the content of the copy to indicate the include and lib paths are PREFIX/lib/InsightToolkit-3.12/
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.12/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.12 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 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
 
 
== 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).
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).
== Note on Python Wrapping ==


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


== The Portfiles ==
== The Portfiles ==
Line 104: Line 112:
For the curious, the details of the port are all in the pseudo tcl script called the 'Portfile', see:
For the curious, the details of the port are all in the pseudo tcl script called the 'Portfile', see:


  https://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile
  http://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile
 
A proposed revision for the MacPorts cmake port is at:
 
https://svn.macosforge.org/repository/macports/users/dweber/devel/cmake/Portfile


If you want to use these Portfiles directly, you can follow the guide instructions at:
If you want to use these Portfiles directly, you can follow the guide instructions at:

Revision as of 18:01, 12 June 2009

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


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


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