[Insight-developers] HDF5, ThirdParty code and GDCM

[Bill Lorensen]

Folks,

Kent has a gerrit topic:
http://review.source.kitware.com/#change,1250

that uses a CMake External project to introduce a package needed to store
and retrieve composite itk transfroms.

This is an important experiment. We have had a variety of experiences
integrating third party code into ITK. Typically, these packages do not have
the same quality and platform goals that we have in ITK.

We have had a positive experience with vnl. Here, we have been able to push
our changes into vnl and integrate vnl releases into ITK. This is mainly
because Brad K is a respected developer for both ITK and VXL and he has
taken responsibility to keep the two code bases harmonious. And vnl is an
integral part of ITK. We need this high level of

For png, zlib, tiff we do not have connections to the developers and it is
somewhat painful to integrate a new version. Here we do not typically push
our changes back to the package developers.

MetaIO and kwsys are kept in-sync because the same code base is used in ITK
and VTK. These packages each have a repository that is shared between
multiple packages and commit privileges are limited to a few developers.
This process works great.

expat is so stable that we never have to touch it.

With GDCM2 we are struggling to keep the GDCM code in sync with the gdcm
repository. The number of warnings and failing tests is improving, but in
general is not up to the quality standards we expect in ITK. Its warnings
and failing tests reported on the ITK dashboard adversely affect the ITK
development process. We need a better process for GDCM.

Back to HDF5. It is a large package and I suspect that if we were to bring
it into ThirdParty we would have another package that interferes with our
development. Using as an external package seems like a great idea. The
challenge will be to integrate into our cmake build process. Fortunately,
the cmake external package mechanism facilitates this.

Once we refine the HDF5 integration, I suggest that we use a similar process
for GDCM. We can take snapshots from GDCM when the GDCM developers make a
release. We will only see warnings that are ITK-specific. Now we see
warnings in code that we do not even use.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110329/c2535b83/attachment.htm>