Osx 108 builds

Here are the steps involved in building OSX release on the LLNL SQA Lab machine

Get Account on 10.8 System

  1. If you have not already done so, get an account on the OSX machine in the SQA lab
  2. You will probably have to request the account directly with Jim Reus, Rena Echeverria-Thomason and probably Garry Schmere
  3. Be sure to request an account with admin. privileges
  4. The account is a local-access account only, but its fine if you wanna use the same info as your AD credentials
  5. Rena or whoever does the work has to physically walk to where the machine is in the SQA lab and add the account
  6. Its best that you also confirm your access to the machine by logging into directly while in the SQA lab
  7. Once you have an account, you can push and pull stuff to/from it from a machine outside the SQA lab. However, the machine itself cannot see any network outside of the tiny SQA lab network.
  8. To access the machine, you go through a proxy machine and specify a magic port number
    • ssh -l <username> -p 7922 stubb.llnl.gov
    • Note: be aware that ssh uses lowercase -p for port number whereas scp uses uppercase -P for port number.

Initial, One-Time Setup of Masonry

  1. If this is the first time you are using masonry here, you will need to also get GNU Fortran, Boost and MPI compiler wrappers set up
    • get gfortran here, http://prdownloads.sourceforge.net/hpc/gfortran-4.7-bin.tar.gz?download
      • Copy and untar the gfortran-4.7 tarball in a convenient place (I just did it into /Users/miller86/VisIt)
        • That will create a bin dir the with gfortran executable all ready for use.
    • Copy and build the boost tarball
      • Untar it and cd to its source dir
      • ./bootstrap.sh --prefix=path/to/installation/prefix
      • ./b2 install
    • Set up your path so that it has gfortran compiler
      • export PATH=$PATH::/Users/miller86/VisIt/gfortran-4.7/usr/local/bin
      • Remember you need to do this before running masonry whenever you plan to build VisIt

Preparing to do a Release Build

  1. It is best to work from a tagged version of the release instead of from the release candidate branch. So, make sure the release manager has already tagged the release. In the examples below, we are using 2.12.1 as the version number which is part of the 2.12RC branch. Nonetheless, if the release has not been tagged, you can still make this work.
  2. Do a checkout of the svn_bin dir on either the RC or Tag depending on which you are planning on using
    • svn co svn+ssh://<NERSC-UNAME@edison.nersc.gov/project/projectdirs/visit/svn/visit/tags/2.12.2/src/svn_bin svn_bin_2.12.2
  3. Do an sdt checkout of the RC or the Tag on another system
    • ./svn_bin_2.12.2/co_rctrunk 2.12RC sdt
    • This will produce a directory named someting like
      2.12RC_trunk
      with src, test and data within it
  4. Create a file named SVN_REVISION in the src dir with the svn revision number in it
    • pushd 2.12RC_trunk/src; svnversion > SVN_REVISION; popd
  5. Remove the .svn dir(s) from each of the src, test and data dirs (they just get in the way and slow down scp operations)
    • pushd 2.12RC_trunk; find . -depth -name .svn -exec rm -rf {} \; popd
    • Note that this will destroy the use of this working copy as an svn checkout. If don't wanna do that, make a copy of it with
      cp -r
      before removing the .svn dir(s).
  6. Do a checkout of the Third Party Libraries dir
    • svn co svn+ssh://<NERSC-UNAME>@edison.nersc.gov/project/projectdirs/visit/svn/visit/tags/2.12.1/third_party 2.12RC_third_party
  7. Remove the .svn dir(s) from 2.12RC_third_party
    • pushd 2.12RC_third_party; find . -depth -name .svn -exec rm -rf {} \; popd
  8. Tar up the 2.12RC_trunk dirtree and the third_party dir and copy to the SQA machine
    • tar cvf - 2.12RC_trunk | gzip --best > visit_2.12RC_trunk.tar.gz
    • tar cvf 2.12RC_third_party.tar 2.12RC_third_party
      • Don't attempt to compress it because all the tarballs there are already compressed
    • scp -P 7922 *.tar* <username>@stubb.llnl.gov:<target-dir>

Using Masonry to do the Build

  1. Be sure to set your path so that the fortran compiler can be found
    • export PATH=$PATH::<path-to-fortran-download>/gfortran-4.7/usr/local/bin
  2. Create a new options .json file for this build in the opts directory
    • cd masonry/opts
    • cp mb-<OLD V#>-darwin-10.8-x86_64-release.json mb-<NEW V#>-darwin-10.8-x86_64-release.json
    • edit the copied file to reflect version number changes and enable/disable any 3rd party libraries as necessary
      • You can use
        "branch":"2.12.1RC",
        in place of
        "tag" : "2.12.1",
        to inform it you are doing build from RC instead of a Tag.
      • Be aware of additional args to build_visit you may need and include in the string valued argument for the "args" member of "build_visit"
      • Be aware of the third party libraries you should (or should not) build.
  3. Next, prepare the directory where masonry will do its magic
    • cd ..
    • mkdir mb-<NEW V#>-darwin-10.8-x86_64
    • cd mb-<NEW V#>-darwin-10.8-x86_64
      • Untar here the 2.12RC_third_party.tar and 2.12RC_trunk.tar.gz tarfiles you copied over
    • Create the following symlinks...
      • ln -s 2.12RC_third_party thirdparty_shared
      • ln -s 2.12RC_trunk/src .
      • ln -s 2.12RC_trunk/test .
      • ln -s 2.12RC_trunk/data .
  4. Start the build
    • cd ..
    • You should be at the masonry top-level directory
    • python bootstrap_visit.py opts/mb-<NEW V#>-darwin-10.8-x86_64-release.json
      • This will take a while. It builds all of the third-party libraries and then builds VisIt and then packages up the installation files for dmg and .tar.gz files for OSX
    • cd mb-<NEW V#>-darwin-10.8-x86_64/build.release
      • There, you should find VisIt-<NEW V#>.dmg and visit<NEW V#>.tar.gz files
  5. Babysitting the Build
    • Occasionally, things will fail. This is an older system, with older compiler, etc. Sometimes the cause is obvious and some simple manual intervention will fix. Other times, it may take more work. If building a particular library becomes onerous, consider removing it from the build by modifying the opts/mb...json file controlling the build.
    • You should be able to step into the various directories, manipulate things and then restart the build from the top again and again.
    • Sometimes packaging of the dmg file or the tarball fails in strange ways. When this happens, go into cd mb-<NEW V#>-darwin-10.8-x86_64/build.release directory and remove CMakeCache.txt and _CPack_Packackages there. Also, remove ../install.release as well and then try restarting the build.

Notes on various builds

  1. Be sure to have a look at Osx_10.8 notes.
  2. Be sure to get the correct list of libraries to enable for OSX 10.8

2.13.0 Notes

  1. An extra 'v' character in the library names installed for pyside was causing VisIt's CMake to fail to find pyside. Adding additional symlinks at the install point without the 'v' character fixed it.
  2. fastbit version untarred to a dir with 2.3.0.4 but was expecting a dir with 2.3.0. Adding a symlink fixed that.
  3. mfem build failed due to an unrecognized arg to ranlib; manual ranlib fixed
  4. Could not build Uintah due to need for C++11 constructs. It was removed from the build
  5. c++03 compiler flag in vtkqt CMakeLists.txt caused problems. Removing the flag from the CMakeLists.txt file fixed it
  6. The load command for typesystem_widgets.xml in visitpy/pyui/pyside/gui/typesystem.xml caused problems. Commenting out fixed it.
  7. symlinks for Headers, etc, in qwt install point caused problems during packaging. Replacing the links with copies of their target dirs fixed.

2.13.1 Notes

  1. Confirm there are no mpi symbols in the mdserver executables
  2. Needed to remove -std=c++03 from src/vtkqt/CMakeLists.txt
  3. Remove typesystem_widgets from src/visitpy/pyui/pyside/gui/typesystem.xml
  4. Revert MOAB plugin's CMakeList.txt file one revision