[Insight-developers] HDF5, ThirdParty code and GDCM

Wed Mar 30 03:56:29 EDT 2011

Le 30 mars 11 à 05:14, Bill Lorensen a écrit :

> 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?

FFTW is already buildable as an external project

> MINC?
>

SWIG
GCCXML (also already buildable as an external project)
Doxygen

> 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.
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers

-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.itk.org
http://www.mandriva.org  http://www.bepo.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110330/596ae6ab/attachment.pgp>