1. 12 May, 2011 1 commit
    • brugger's avatar
      · b6c07d04
      brugger authored
      1) I added code from Vern Staats that always forces ssh tunneling for all
         data connections. This code is dependent on VISIT_FORCE_SSH_TUNNELING,
         which is off by default. To enable forcing of ssh tunneling do one of
         the following:
         a) Add the line
            to your config site file.
         b) Run cmake with VISIT_FORCE_SSH_TUNNELING defined on the execute line
            as shown below.
      2) I added code from Vern Staats that uses /dev/urandom to create the random
         seed used to generate the key used to set up data connections between
         components. The code is unix specific. This change and the change above
         resolve #702.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@14795 18c085ea-50e0-402c-830e-de6fd14e8384
  2. 30 Mar, 2011 1 commit
  3. 22 Mar, 2011 1 commit
    • miller86's avatar
      How do you override where VisIt obtains a given 3rd party lib from on the · 4dd3f0b0
      miller86 authored
      command-line to CMake? By 'override', I mean change from what the default
      (config-site file says) is?
      Do you specify -DFOO_DIR:PATH=<path> or -DVISIT_FOO_DIR:PATH=<path>?
          Neither worked.
      Is the ':PATH' really necessary?
          Don't know but I am not taking any chances.
      I could not get VisIt's CMake behavior to accept overrides of 3rd party
      libs directory locations using on the command line to CMake. There is
      some stuff going on in CMake where VISIT_3RDPARTY_VAR/DEP macros are
      concerned that I just don't understand.
      For a lib named FOO, here are actions that occured...
      The VISIT_3RDPARTY_VAR/DEP macro summarily called
      However, that SET() call would silently fail (e.g. value of VISIT_FOO_DIR
      would NOT change) if VISIT_FOO_DIR had been previously defined, typicaly
      by a config-site file's VISIT_OPTION_DEFAULT(VISIT_FOO_DIR...) line.
      On the other hand, if VISIT_FOO_DIR had NOT been previously defined then,
      the SET() call would succeed ensuring an entry for FOO was in the cache
      for SetUpThirdParty.cmake to later find.
      Immediately after the above SET() command, the macro would test to see if
      VISIT_FOO_DIR had the value "VISIT_FOO_DIR-NOTFOUND" (in other words, did
      the above SET() operation actually do anything) and if NOT, then copy the
      value of VISIT_FOO_DIR into FOO_DIR.
      Ultimately, it is FOO_DIR that SetUpThirdParty.cmake uses to test/ensure
      a lib is setup correctly. And, the previous logic did take whatever the
      value of VISIT_FOO_DIR was and put it into FOO_DIR. So, I reasoned that
      -DFOO_DIR:PATH=<path> is the correct format for 3rd party lib override
      options on command line to CMake. I adjusted logic in VISIT_3RDPARTY_VAR/DEP
      macros to make that work. I also removed redundant argument to these macros
      (e.g. VISIT_FOO_DIR and FOO_DIR were replaced with just FOO_DIR) so the
      macros generate the 'VISIT_FOO_DIR' symbol given the 'FOO_DIR' symbol. I
      also ensured that when a lib is so overrided, the value cached for
      VISIT_FOO_DIR (is forced to match) matches VISIT_FOO specified on CL.
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@14460 18c085ea-50e0-402c-830e-de6fd14e8384
  4. 16 Feb, 2011 2 commits
  5. 14 Feb, 2011 1 commit
  6. 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"
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@13578 18c085ea-50e0-402c-830e-de6fd14e8384
  7. 12 Jan, 2011 2 commits
  8. 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
  9. 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
  10. 06 Jan, 2011 1 commit
  11. 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
  12. 28 Dec, 2010 1 commit
  13. 20 Dec, 2010 1 commit
  14. 10 Dec, 2010 1 commit
  15. 03 Dec, 2010 1 commit
  16. 30 Nov, 2010 1 commit
  17. 29 Oct, 2010 1 commit
  18. 22 Oct, 2010 1 commit
  19. 19 Oct, 2010 1 commit
  20. 22 Sep, 2010 2 commits
  21. 21 Sep, 2010 1 commit
  22. 08 Sep, 2010 1 commit
  23. 27 Aug, 2010 1 commit
  24. 19 Aug, 2010 2 commits
  25. 16 Aug, 2010 1 commit
  26. 13 Aug, 2010 2 commits
  27. 10 Aug, 2010 1 commit
  28. 05 Aug, 2010 1 commit
  29. 02 Aug, 2010 1 commit
  30. 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
  31. 30 Jul, 2010 1 commit
  32. 29 Jul, 2010 1 commit
  33. 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
  34. 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
  35. 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