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).
This project has been completed. Any further changes can be made on the SVN trunk.
This table lists the actions that comprise this build system project as well as their status.
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
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.
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
- Some source code changes have been made to migrate symbols in visit-config.h to symbols that have a VISIT_ prefix.
- 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 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 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
|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.|
|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.|