[Insight-developers] ITK builtin third-party libraries (was: Update on DICOM)

[Brad King]

On 12/23/2011 12:44 PM, Steve M. Robbins wrote:
> If I may butt in with my Debian maintainer hat on ...

You may.  I know that including third-party dependencies in a project's
build instead of using system-installed versions makes packaging painful.
It also increases our own maintenance burden because we are essentially
keeping our own branches of the projects.  I wish we didn't need to do
this but the approach does lower the barrier to entry significantly for
developers or users on platforms lacking package managers as wonderful
as Debian's.

When designing ITK's modular infrastructure and use of third-party
libraries I wanted to make sure it was possible to package cleanly.
See below.

Side note: I'm a big fan of projects that try to solve this problem
at a level higher than the build system using some kind of package
management that does not need admin rights (0install, NixOS, Ryppl).
If you know of others I'd love to learn about them.

>>    http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/ThirdParty/HDF5/src/README-ITK.txt;hb=v4.0.0
>
> I see that the HDF5 support can be built with a system install of
> HDF5.  From a packager point of view, that is crucial.

Yes.  That is true for most of the third-party modules.

 > I hope you will similarly support a system DCMTK.

Yes.  That's one reason I was bringing this topic up now.

>> This will also allow us to make ITK-specific fixes without waiting
>> for changes to go upstream.
>
> Is there a vision of coordinating with packagers on these ITK-specific
> fixes?

Actually I meant fixes for compiler warnings and to the CMake code
to make the build cleaner inside ITK.  Certainly functional changes
should not be made without coordinating them with the upstream devs.
Otherwise the ITK_USE_SYSTEM_* options wouldn't work.

The design used for the HDF5 import is described in the above-linked
readme.  HDF5 snapshots from upstream stay in a dedicated Git branch
(which is not explicitly named on the server but is merged in) that
has no modifications.  That way we can update to a new snapshot on
that branch and merge the result into ITK.  It is very easy to do a
diff between the ITK version and the original upstream on which it is
based.

 > So it would be awesome if there was a way for me to receive
 > notifications of such.

I've been doing this for years with ITK's use of vxl, though it is made
easier by having my own commit access to vxl.  Every time I update ITK's
vxl (using the same method as for HDF5 above) I look at the changes made
in ITK, identify those that should have gone upstream but didn't, and
send them.  That way when I do the actual update I take an upstream that
is as close to ITK's version as possible.

I won't personally have time to do this for every third-party project we
use.  However perhaps we can arrange for email notification from the
version control system whenever modifications to certain directories
appear in master.  There may be a bunch of false positives but at least
the important changes would be in there.

-Brad