[Insight-developers] HDF5, ThirdParty code and GDCM

[Bill Lorensen]

May there is a way to accomplish what we want without a superbuild. Or maybe
we need a superbuild.

Let's list the packages that might qualify as external packages:

HDF5
GDCM
FFTW?
MINC?

others?

On Tue, Mar 29, 2011 at 10:58 PM, Williams, Norman K <
norman-k-williams at uiowa.edu> wrote:

>  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/20110329/a656c745/attachment.htm>