Mac install under CMake

The installation process for MacOS X is largely the same as the installation process for UNIX. You use make install to install VisIt and make package to create a binary distribution. This page explains some of the subtleties of the MacOS X installation in the CMake coding that describes the build system because some additional steps are needed to make sure the install works.

Executable path

After the transition to cmake, the build_visit script creates shared libraries that contain the whole path to the shared library and their dependencies. This is much how like Linux can embed paths into shared libraries using rpath. The shared libraries must contain their entire path so that development versions of VisIt (read not installed yet) can still operate without having to create links to libraries or copy libraries into the src/lib directory. Upon installation, the 3rd party libraries upon which VisIt depends are installed as part of the VisIt system, thus making it possible to separate VisIt from its development environment.

As part of the installation process, cmake already renames some of the library dependencies in each executable and shared library. This happens all the time and on the Mac we set the CMAKE_INSTALL_NAME_DIR option to @executable_path/../lib to make the VisIt libraries "execute relative". This step replaces absolute paths in the executables and shared libraries with @executable_path/../lib, which prepares the VisIt installation to be self-contained so it may be copied to other computers.

Unfortunately, cmake does not rename or modify 3rd party dependent libraries.

How renaming works

VisIt's build system has extra logic to perform the necessary renaming for 3rd party dependent libraries (e.g. VTK, Qt) so the installation can be self-contained. The renaming machinery that is used is based on a script called src/CMake/osxfixup that can replace absolute paths beginning with /Users with @executable_path/../lib. This does assume that you will be building VisIt in your home directory but that's probably a fine assumption for now. The osxfixup script uses the Mac's install_name_tool utility to perform the changes to the libraries.

In order to make sure that osxfixup operates on all shared libraries and executables, the main CMakeLists.txt contains some logic in its installation macros that add a custom install/code rule for MacOS X. The custom install step calls osxfixup after its target is installed so the osxfixup script will operate on the target and convert its absolute paths to executable relative paths. Most of these custom osxfixup calls are made in the top level CMakeLists.txt file. Some additional calls are made in the src/CMake/ThirdPartyInstallLibrary.cmake file to ensure that 3rd party libraries are "fixed up" as they are installed or packaged.

Known Issues

VisIt Build Failure on OSX

VisIt has the possibility to fail during build if you have a different version of Qt installed on the system. This is due to a bug with CMake's module FindQt4.cmake where QT_QTCORE_INCLUDE_DIR is incorrectly set to find the system path instead of the path from VisIt's install of QT. Kitware has issued a fix for this bug: Bug Report .

There are two solutions available:

1. Replace the default FindQt4.cmake in CMake's installed Modules directory at ${VISIT_THIRDPARTY_PATH}/cmake/2.8.3/linux-i686_gcc-4.4/share/cmake-2.8/Modules with the fixed FindQt4.cmake

2. Modify the build_visit script to download a newer version of CMake that includes the bug fix.


Bug Report
Diff
FindQt4.cmake