Cross-Platform Build

VisIt compiles on multiple platforms, mostly using an autoconf/make type of build. On Windows, however, we build VisIt using MS Visual Studio and thus require the use of project files. Project files are vastly different from the Makefiles used on UNIX systems and require special maintenance by a single developer. This places an undue burden on the Windows developer. Now is the time to change VisIt's build system so a single set of files that describes the build are maintained. Ideally, this single set of files could target various build systems so that developers can use their favorite build environments (make, Visual Studio, XCode, and so on).

Helping out

This project has been completed. Any further changes can be made on the SVN trunk.

Project status

This table lists the actions that comprise this build system project as well as their status.

Phase I

These should be done before merging to the trunk.

Action items More information Status
cmake Install cmake 2.6.4 on all LLNL systems status
configure Create CMake replacement for configure, identifying all of the high-level configurable variables that we'll need Done
visit-config.h How does CMake create visit-config.h? Done
multi-platform Test creation of Makefiles, project files, Xcode files from CMake input Makefiles work, Xcode needs some more testing, Windows needs some more testing
libraries Create CMake build scripts for libraries Done
Ice-T Add support for Ice-T. Make it a configurable option and set it up by default in the host.cmake files for platforms where we already support Ice-T. Done
Add support for remaining I/O libraries FASTBIT,Boxlib, Mili, ViSUS,ITAPS Done
Solution for src/lib VisIt currently assumes its 3rd party libraries will exist in src/lib when we go to run VisIt. We no longer create symlinks there. I guess the solution is to rebuild all Mac libraries so they do not use @executable_path so we can run without installing. Then, during installation, we can convert all VisIt and 3rd party libraries to @executable_path. The Linux and Windows strategies need to be determined. I added install targets that install all of the relevant libraries during "make install". The libraries are found via rpath during a normal run.
library dependencies We may need to detangle some library dependencies by moving code around We've snipped some dependencies but we can do more between AVT and visit_vtk. Actually, things are better now but we could still look some more
plugins Figure out what CMake should do with plugins. This will likely involve changing xml2makefile to create CMake input. Done. We created xml2cmake that generates CMakeLists.txt from the XML file. We check in the CMakeLists.txt file so it's available.
testing Create config-sites for all LLNL platforms and on Windows,Mac,Linux status
out-of-source builds Allow builds to take place outside of source directory, useful when building for multiple platforms Done and works subject to libraries in lib
build_visit build_visit will need some changes Done
building plugins against installed VisIt Building plugins against installed VisIt will require changes. We may want to include the cmake binaries in our installations now to make things easier. Done
source_files We'll need to change source_files so we can get our actual list of files that go into a distribution some other way. Done
visit-build-open/visit-build-closed We'll need to change these scripts to use cmake. They currently use configure. Done - worked on hoth
finish tools There are still a lot of CMakeList.txt that need to be created in src/tools. See src/tools/CMakeLists.txt for more information. Mili needs to be handled specially. qtssh only needs to build on Windows. Done
Finish CLI/scripting plugins I created projects to generate the CLI and its modules. There's a mismatch in the variable defined by the FindVisItPython routine and what the plugin .cmake files are expecting. Patch up the plugin cmake files and also change xml2cmake to use the right variable. Done
Java interface Add support for building the Java interface. It should still be optional. Done
-fvisibility=hidden Add support for -fvisibility=hidden Done
VISIT_ options Add VISIT_ options for all of our 3rd party libraries so they can be supplied on the cmake command line. Done
libsim Make sure libsim gets built and installed -- at least for Linux/Mac. Done
data Make sure the data directory gets built when it is present. Done
test suite Make sure the test suite still can build VisIt and run -- did we CMakeLists.txt the data dir? Works individually and the regression script has been modified but not tested.

Phase I Details

Expand on the phase 1 tasks so we can track what's really done.

Installing CMake on LLNL/LBL platforms

Machine Status
dantooine Done
davinci Done
hoth Done
uP Done
yana Done
crier Done
hopi Done
purple Done
Windows Done

Creating config-site files

This is the list of config-site files that must be done in order to consider this task completed for phase 1. All non-LLNL config-sites have had a CMake equivalent created via a translation script. These may require some fine-tuning but they should generally be correct.

Machine Status
dantooine Done
davinci Done
hoth Done
uP Done
yana Done
crier Done
hopi Done
purple Done
Windows Done

Phase II

These can be done after the merge to the trunk.

Action items More information Status
remove old build system Remove the old build system Done
static build Allow a static build of VisIt Done
implement dbio-only build Our current configure recently supports dbio-only builds Done
implement engine-only build Our current configure recently supports engine-only builds that only build the engine and skip a lot of junk. Done
make install Setup install logic in the cmake files that would enable "make install" to work from the top level directory. Done

Changes that have been made

  1. Some source code changes have been made to migrate symbols in visit-config.h to symbols that have a VISIT_ prefix.
  2. Some changes need to be made to the way VTK gets installed. For example: the CMake directory from VTK needs to be installed as do VTKConfig.cmake, and UseVTK.cmake. These probably would be installed if we just did "make install" for VTK instead of whatever we're doing right now. Another thing that I ran into is that VTKConfig.cmake expects VTK libs to be stored in a "bin" directory, which does not match how we had it installed.

Broader changes and things to remember

Regardless of which build system, we ultimately use, there are some things to keep in mind when we create the new projects:

  • By default, we should use mpiCC for the parallel compiler so we don't have to specify parallel options. If that's not acceptable, we should still have some variable for the parallel compiler and flags that go along with it. We currently append MPI options to our CXXFLAGS so all of our sources are built with MPI-related flags. This is just dumb.
  • Keep in mind that we often build parallel .o's next to serial .o's. We do similar things with OpenGL source vs Mesa source. What I'm saying is that sometimes a single source file gets built multiple times with different compiler flags
  • We sometimes automatically generate source code (Qt moc files).
  • Make it easy to produce:
    • static build
    • build only engine,mdserver,plugins
  • How are 3rd party built-ins to be handled? Maybe we should remove them. Otherwise, we need to create our own CMake build scripts for them that tie them into our build.
  • For Windows, we need to link a DLL with all of its dependent libraries. This means that we'll need to add libraries to link with for producing our shared libraries.
  • We need to be able to create symlinks in the lib directory to external 3rd party .so's as before. Alternatively, we need to copy them into lib.
  • For Mac, we need to set the install target for a library so it's relative to @executable_path. Maybe to get VisIt working with XCode, more changes are required...

Possible build tools

We have identified two plausible cross platform build tools: SCons and CMake. CMake is probably more mature as it is used to build VTK and KDE.

SCons

SCons is a Python-based cross platform build environment for command line builds. SCons has many advanced features, including batch builds, dependencies,...

For more information, see: SCons web site

CMake

CMake enables cross-platform builds using the build environment of your choice. The CMake projects are used to generate Makefiles, project files, etc for system and compiler of your choice. CMake is used by many projects, including VTK and KDE.

For more information, see: [CMake project site].

Comparison of features

Features/Tools SCons CMake
Scripting language Python CMake script
Supports multiple build environments No, all builds use scons command line Yes, CMake scripts generate projects for Windows for several compilers, Makefiles for UNIX, XCode for Mac.
Batch builds yes  
Caching yes no, though it may be possible to separately use ccache as the compiler.
Parallel builds Yes, and it always keeps N processors active, regardless of how many files are in the directory hiearchy Yes, with make (subject to make's limitations)
New dependency? Yes No, we already use CMake for VTK builds, which means we wouldn't have to install it.
Custom detection routines Yes, the user can write custom header file or function detection routines in Python and register them with SCons. This is very flexible. Also, since it's Python-based, we could easily write a function to use the existing machine.conf files that we have for our LLNL computers. Yes. CMake provides functions for testing for features, finding libraries, etc. Find routines are also available for many 3rd party libraries, which means we can reuse a lot of what other developers have written in the way of detection routines.