1. 22 Sep, 2010 2 commits
  2. 21 Sep, 2010 1 commit
  3. 08 Sep, 2010 1 commit
  4. 27 Aug, 2010 1 commit
  5. 19 Aug, 2010 2 commits
  6. 16 Aug, 2010 1 commit
  7. 13 Aug, 2010 2 commits
  8. 10 Aug, 2010 1 commit
  9. 05 Aug, 2010 1 commit
  10. 02 Aug, 2010 1 commit
  11. 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
  12. 30 Jul, 2010 1 commit
  13. 29 Jul, 2010 1 commit
  14. 17 Jun, 2010 1 commit
    • brugger's avatar
      · 1bf9470d
      brugger authored
      1) I modified the main CMakeLists.txt to add -DMPICH_IGNORE_CXX_SEEK
         wherever -DPARALLEL is specified to eliminate a compile failure with
         some versions of mpi. I also removed all references to the flag
         -DMPICH_IGNORE_CXX_SEEK from any makefiles that had it since it was
         no longer needed.
      2) I corrected a minor error in the alastor regression suite script.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@11697 18c085ea-50e0-402c-830e-de6fd14e8384
  15. 09 Jun, 2010 1 commit
    • brugger's avatar
      · 0a0cf60a
      brugger authored
      I reverted the changes to the logic that adds the "current" link to
      the installation when doing a "make install" to the previous behavior.
      I then modified the frontendlaucher so that it works without the
      "current" link present since our prepackaged distribution will not
      have it. The frontendlauncher now sorts the installed version and takes
      the last one and uses that as the current version if the "current" link
      is missing.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@11613 18c085ea-50e0-402c-830e-de6fd14e8384
  16. 08 Jun, 2010 1 commit
    • brugger's avatar
      · a852fa7a
      brugger authored
      I corrected the code that adds a "current" symbolic link to a binary
      distribution created by CPACK, that I then commented out since CPACK
      doesn't handle symbolic links properly. I am now going to pursue a
      route of adding the current link as a postprocessing step in the
      visit-build-open script. When the bug is fixed in cmake the lines can
      be uncommented. I am not to hopeful since there are several tickets
      in cmake's bug tracker related to this going back about 3 years.
      Information on the CPACK bug:
      Currently CPACK removes all symbolic links and replaces files with hard
      links. If a symbolic link is to a directory it creates a hard link for
      every file in the directory hierarchy that the link points to. Besides
      being wasteful it can also create an invalid tar file since it only
      stores 100 characters of hard link information in the tar file, which
      we run into with some of our files in the include directory.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@11601 18c085ea-50e0-402c-830e-de6fd14e8384
  17. 04 Jun, 2010 1 commit
  18. 25 May, 2010 1 commit
  19. 12 May, 2010 1 commit
  20. 11 May, 2010 1 commit
  21. 06 May, 2010 1 commit
    • brugger's avatar
      · 63eef339
      brugger authored
      I corrected the rpath detection logic in CMakeLists.txt to handle the
      case were there were multiple rpaths.  In particular, INSTALL_RPATH was
      being set as a list of rpaths (the rpaths end up semi-colon separated)
      and I changed it to a string of space separated rpaths.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@11266 18c085ea-50e0-402c-830e-de6fd14e8384
  22. 30 Apr, 2010 1 commit
  23. 29 Apr, 2010 4 commits
  24. 28 Apr, 2010 1 commit
  25. 27 Apr, 2010 1 commit
  26. 21 Apr, 2010 1 commit
  27. 19 Apr, 2010 1 commit
  28. 14 Apr, 2010 1 commit
  29. 13 Apr, 2010 1 commit
  30. 09 Apr, 2010 1 commit
  31. 08 Apr, 2010 2 commits
  32. 01 Apr, 2010 1 commit
  33. 24 Mar, 2010 1 commit