• miller86's avatar
    Fixed problems with FindXdmf. It was only third party lib support function · ed4f3dc8
    miller86 authored
    using FIND_PACKAGE and was explicitly setting XDMF_DIR, both of which are
    intended to be handled by SET_UP_THIRD_PARTY.
    Added ${HDF5_XXX_DIR} refs to Xdmf.xml. Why? The Xdmf plugin doesn't use
    HDF5 does it? Yes, thats correct. It does not. However, either we are using
    Xdmf lib header files incorrectly or Xdmf lib is itself flawed in this
    regard but by virtue of include dependencies, our Xdmf plugin is indeed
    including hdf5.h as well as other HDF5 header files. So, the Xdmf plugin
    is presently DIRECTLY dependent on HDF5 and therefore needs HDF5 lib
    variables in its .xml file.
    Note, if the Xdmf plugin was not DIRECTLY dependent on HDF5, and only
    indirectly through Xdmf library's use of HDF5 itself, then
    VISIT_XDMF_LIBDEP would be the correct way to handle that.
    Found and fixed the opposite problem with H5Part. The H5Part plugin is
    DIRECTLY dependent on a number of libraries including HDF5, FASTBIT,
    SZIP. And, the .xml file for H5Part captures this dependency by
    including all the lib INCLUDE_DIR and LIB_DIR variables. However, we
    were also defining LIBDEP variable for it in CMakeLists.txt as well
    as many config-site files and that is not appropriate for H5Part.
    git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@12076 18c085ea-50e0-402c-830e-de6fd14e8384
CMakeLists.txt 72.7 KB