Just thinking out loud, but we could make building HDF5 an "external_project" call instead. This will download/update, configure, build and install hdf5 and then in ParaView we can just FindPackage(HDF5) and give our internal build tree as a hint. We would leave the USE_SYSTEM_HDF5 logic in place and if it is OFF then external_project will be called.<br>
<br><div class="gmail_quote">On Thu, Apr 15, 2010 at 6:30 AM, Biddiscombe, John A. <span dir="ltr"><<a href="mailto:biddisco@cscs.ch">biddisco@cscs.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I have been rethinking my strategy.<br>
<br>
Since hdf5 is now cmakeified (or will be released with it soon), I don't see any point in having it inside paraview. All that is required is that people use FindHDF5 to pick it up. If it's there, use it, if not, don't. I'm not happy making a nice cmakeified hdf5 that builds inside another project and obeys all the install rules etc and other wrinkles.<br>
<br>
People wanting hdf5-1.8.x can simply install it (using cmake if they want) and use it with the current paraview.<br>
<br>
Why was it included inside PV in the first place. I don't really believe it needs to be there.<br>
<br>
Thoughts ?<br>
<div><div></div><div class="h5"><br>
JB<br>
_______________________________________________<br>
Paraview-developers mailing list<br>
<a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
<a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
</div></div></blockquote></div><br>