The ITK packaging saga...

| No Comments

Flying in the face of conventional wisdom, I decide that my first real packaging task for Debian is going to be The Insight Toolkit (ITK), a set of medical image processing libraries, for segmentation and registration. (I use this for my research.)

ITK is large, complex, has a non-trivial build system, consists of multiple shared libraries, Doxygen documentation, example programs, applications, and more. Typically the sort of thing you would avoid trying to package, at least until you had packaged some simpler programs.

I love a good challenge...

I started the packaging process a few weeks ago, beginning by examining how VTK is packaged. It is from a related project, and uses the same build tool (CMake). So I set about figuring out how to make it build. It turns out that the first 90% took about 10% of the effort...

The first problem was getting CMake to behave. Since Debian has very strict packaging guidelines, I needed to make sure the end result of the build would follow policy. And I needed to automate the build process, whereas you typically use CMake interactively to set it up.

Fortunately, after Maitland Bottoms (VTK maintainer) advised me on how to prime the build process with the CMakeCache file, I got the build going.

After a while, I got the control, rules and other related debian/* files set up mostly properly, and got a build going. With a small amount of tweaking, I eventually had the thing building.

But ITK puts the libraries in /usr/lib/InsightToolkit, along with the .cmake configuration files. If I left them there, it would potentially go against policy (not sure on that point) and it would certainly require modifying /etc/ld.so.conf, something I didn't want to do lightly. Instead I chose to move the libraries up to /usr/lib, leave the cmake files where they were, and change the build scripts to suit. A few more tweaks later, and it was mostly working ok.

But then came the shared libraries...

Leave a comment