1. 14 Feb, 2011 1 commit
  2. 18 Jan, 2011 1 commit
    • brugger's avatar
      · b22d9fd2
      brugger authored
      I updated the copyright dates in the copyright notice in all the "*.c",
      "*.C", "*.h", "*.java", "*.cmake", "*.txt" and "*.in" files in the "src"
      directory.
      
      
      
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@13578 18c085ea-50e0-402c-830e-de6fd14e8384
      b22d9fd2
  3. 12 Jan, 2011 2 commits
  4. 11 Jan, 2011 1 commit
    • miller86's avatar
      I fixed a performance issue in Namescheme utility where it would build · 75d291e2
      miller86 authored
      up and then tear down each conversion spec's evaluation tree upon an
      invokation of the GetName method.
      
      I fixed a leak destructing DebugStreams that has been there since 2004.
      
      I added various of the unit test codes in src/common/utility to common's
      CMakeList.txt so that they get compiled by default.
      
      I added a new 'unit' class of tests and added the unit tests from
      src/common/utility there.
      
      I removed mdserver/main/testmds.C as whatever testing that afforded is
      fully subsumbed by VisIt's normal testing.
      
      I fixed a cut-n-paste error in top level CMakeLists.txt where include
      paths for several dirs in src/common were incorrect.
      
      
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@13476 18c085ea-50e0-402c-830e-de6fd14e8384
      75d291e2
  5. 07 Jan, 2011 1 commit
    • brugger's avatar
      · 9b95c44b
      brugger authored
      1) I replaced the BOXLIB2D and BOXLIB3D symbols with just BOXLIB in our
         cmake stuff. This resolves #534.
      
      2) I removed the header file for xml2makefile since it is obsolete.
      
      
      
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@13462 18c085ea-50e0-402c-830e-de6fd14e8384
      9b95c44b
  6. 06 Jan, 2011 1 commit
  7. 05 Jan, 2011 1 commit
    • bonnell's avatar
      Added 'FOLDER' property to plugins, third-party-builtin, and tools, which... · 6d136b0b
      bonnell authored
      Added 'FOLDER' property to plugins, third-party-builtin, and tools, which groups projects into the designated folder.  This will clean up the Visual Studio IDE and make it easier to find a project of interest when debugging.  Should have no effect for generators that do not use this property.
      
      Updated GenerateCMake.h and re-ran xml2cmake on all plugins.  Fixed a few xml files so that xml2cmake would generate the correct CMakeList.txt file.  Changed a couple of xml files to use consistent naming for include directories (VISIT_INCLUDE_DIR instead of VISIT_SOURCE_DIR).
      
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@13437 18c085ea-50e0-402c-830e-de6fd14e8384
      6d136b0b
  8. 28 Dec, 2010 1 commit
  9. 20 Dec, 2010 1 commit
  10. 10 Dec, 2010 1 commit
  11. 03 Dec, 2010 1 commit
  12. 30 Nov, 2010 1 commit
  13. 29 Oct, 2010 1 commit
  14. 22 Oct, 2010 1 commit
  15. 19 Oct, 2010 1 commit
  16. 22 Sep, 2010 2 commits
  17. 21 Sep, 2010 1 commit
  18. 08 Sep, 2010 1 commit
  19. 27 Aug, 2010 1 commit
  20. 19 Aug, 2010 2 commits
  21. 16 Aug, 2010 1 commit
  22. 13 Aug, 2010 2 commits
  23. 10 Aug, 2010 1 commit
  24. 05 Aug, 2010 1 commit
  25. 02 Aug, 2010 1 commit
  26. 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
      ed4f3dc8
  27. 30 Jul, 2010 1 commit
  28. 29 Jul, 2010 1 commit
  29. 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
      1bf9470d
  30. 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
      0a0cf60a
  31. 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
      a852fa7a
  32. 04 Jun, 2010 1 commit
  33. 25 May, 2010 1 commit
  34. 12 May, 2010 1 commit
  35. 11 May, 2010 1 commit
  36. 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
      63eef339