[Insight-developers] HDF5, ThirdParty code and GDCM

[Williams, Norman K]

As it happens, my HDF5 IO patch requires an internal build of HDF5.  And the HDF5 people have embraced CMake enthusiastically, if a little idiosyncratically.  The ONLY way it works correctly is with



find_package(hdf5 NO_MODULE)



And they store the hdf5-config.cmake in ${CMAKE_INSTALL_PREFIX}/share/cmake/hdf-${hdf5-version}



I do have the ExternalProject recipe for HDF5, which is straightforward. The problem is one of build precedence: In order for CMake to manage file header dependencies, all the headers need to exist at configuration time.   So it isn't really possible to just include the ExternalProject recipe for HDF5 in the CMakeLists.txt for ITK.



Which is why I brought up integrating ExternalProject into building ITK -- in order to build e.g. HDF5 and configure ITK to find it, you need a 'Superbuild' (the slicer coinage) that builds the prerequisites as ExternalProjects and then builds ITK as an external project.

________________________________
From: insight-developers-bounces at itk.org [insight-developers-bounces at itk.org] on behalf of Bill Lorensen [bill.lorensen at gmail.com]
Sent: Tuesday, March 29, 2011 8:54 PM
To: Insight Developers
Subject: [Insight-developers] HDF5, ThirdParty code and GDCM

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


________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110330/74cbd239/attachment.htm>