[Paraview-developers] Moving to hdf5-1.8.x

[Biddiscombe, John A.]

After ranting on a bit yesterday, I had another go at the install rules and found that removing all the complicated if stuff I put in makes it simpler and it errr still works. So that's nice.

Question.

Assuming I go ahead with it ...Do I put the entire hdf distribution under utilites - or just the bits that we need for paraview support? (ie skip most tools/examples/cpp bindings/fortran etc etc).

JB

> -----Original Message-----
> From: Biddiscombe, John A.
> Sent: 15 April 2010 21:38
> To: Biddiscombe, John A.; Moreland, Kenneth; Utkarsh Ayachit
> Cc: paraview-developers at paraview.org
> Subject: RE: [Paraview-developers] Moving to hdf5-1.8.x
> 
> and paraview uses old style cmake 2.6 ways of doing installs and doesn'r use
> the newer
>   INSTALL (
>     TARGETS
>       ${HDF5_LIB_TARGET}
>     EXPORT
>       ${HDF5_EXPORTED_TARGETS}
>     LIBRARY DESTINATION lib
>     ARCHIVE DESTINATION lib
>     RUNTIME DESTINATION bin
>   )
> 
> type. uses the old (deprecated) output directory stuff rather than the newer
> SET (CMAKE_RUNTIME_OUTPUT_DIRECTORY etc etc
> 
> lots of issues that make things tedious.
> 
> It can be done, and does work, just messy and would be better external, so
> many fudges could be removed. just configure, generate and then pick up the
> Hdf5-config.cmake file which is generated by the (very nice) new install
> system
> 
> JB
> 
> > -----Original Message-----
> > From: paraview-developers-bounces at paraview.org [mailto:paraview-
> developers-
> > bounces at paraview.org] On Behalf Of Biddiscombe, John A.
> > Sent: 15 April 2010 21:21
> > To: Moreland, Kenneth; Utkarsh Ayachit
> > Cc: paraview-developers at paraview.org
> > Subject: Re: [Paraview-developers] Moving to hdf5-1.8.x
> >
> > > I am confused about why take out HDF5 now that it is converted to CMake.
> > > That should make it easer to cram it into ParaView.
> >
> > hdf being properly cmakeified makes it harder than it used to be,
> previously
> > we just bodged it and it was ok, but now
> > 1) vtkhdf5 instead of hdf5 - have to override hdf5_EXPORTS otherwise dll's
> > don't work, also have to make sure that projects using pv as a library get
> > the right names, it was a hack in the current version.
> > 2) findZlib inside hdf5 won't pick up vtkzlib unless we force things - I
> > don't want to wrap every single hdf5 option inside an IF overridden by
> > parent project ....clause
> > 3) make install needs to be overridden inside hdf5 to pick up the targets
> > and install them alongside pv - and get the names right
> > 4) every time I get it working, someone else breaks it and I'm tired of
> > redoing it again and again.
> > 5) Override options for parallel, fortran, tools, other libs, do we let
> the
> > user have complete freedom to configure all these or not. All extra work
> now
> > that hdf5 proper has dozens of possibilities.
> > 6) I'd like to findhdf5 cleanly but we have internal build, external
> build,
> > old non cmakeified 1.8, older 1.6, other flavours. got to get all
> > consistent.
> >
> > I'm fed up with it and want to do something else. A simple external hdf
> > configured and built independently makes life easier.
> >
> > I thought that the cmake externalproject_add() was going to save me, but
> it
> > turns to not work the way I thought.
> >
> > There really needs to be a proper external project method whereby a sub
> > project can be build and integrated cleanly using a simple findXXX.
> >
> > JB
> > _______________________________________________
> > Paraview-developers mailing list
> > Paraview-developers at paraview.org
> > http://public.kitware.com/mailman/listinfo/paraview-developers