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.