1. 09 Nov, 2014 1 commit
  2. 12 Feb, 2014 1 commit
  3. 18 Jan, 2014 1 commit
  4. 15 Jan, 2014 1 commit
  5. 09 May, 2013 1 commit
  6. 25 Jan, 2013 1 commit
  7. 16 Jan, 2013 1 commit
  8. 26 Dec, 2012 1 commit
    • brugger's avatar
      1) I modified libsimV2 to build both a static and dynamic library (simV2 · ee3b0449
      brugger authored
         and simV2dyn) and then modified the python binding to use the dynamic
         library. With this change it is no longer necessary to manually set the
         VISIT_C_FLAGS and VISIT_CXX_FLAGS to include -fPIC since CMake adds the
         flags if building a shared library. This resolves #1288.
      2) I modified build_visit to no longer add -fPIC to the VISIT_C_FLAGS
         and VISIT_CXX_FLAGS. I then removed -fPIC from the VISIT_C_FLAGS and
         VISIT_CXX_FLAGS in all the config site files.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@19904 18c085ea-50e0-402c-830e-de6fd14e8384
  9. 06 Dec, 2012 1 commit
  10. 08 Nov, 2012 1 commit
  11. 19 May, 2011 1 commit
  12. 16 Feb, 2011 1 commit
  13. 31 Jul, 2010 1 commit
    • 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
  14. 23 Apr, 2010 1 commit
  15. 29 Jan, 2010 1 commit
  16. 18 Dec, 2009 1 commit