CMake

CMake is a system for generating per-platform build files. Visit cmake.org for general information about CMake.

Linden Lab switched to CMake for building the Second Life viewer (starting with version 1.21).

Introduction to CMake

CMake has the advantage of generating per-platform build files for us. On Linux, it will generate Makefiles and KDevelop project files. On OS X, it will generate Makefiles and Xcode project files. On Windows, it will generate Makefiles (for nmake) and Visual Studio project files.

All of the "smarts" stay in the CMake files, so there's just one authoritative source of build knowledge. This means that people can use the development environment they prefer without having to worry so much about breaking other people's builds. Because CMake files are plain text, merging is easy, as is maintaining experimental patches.

CMake tells your build system how to rebuild its input files when it detects changes to CMake's configuration files. This means that you only need to run cmake once. After that, make or your IDE should keep the CMake files and its own project files in sync for you.

Performing a build with CMake

Per platform build instructions for CMake-based builds of the Second Life viewer are available for these platforms:

• Microsoft Windows
• Mac OS X
• Linux

Prebuilt libraries vs. standalone builds

The develop.py script is designed to create a reasonably sane default configuration for you. By default, this command will configure a "non-standalone" version of the source code tree. This means that the required third party library packages (as built by Linden Lab) will be downloaded during the CMake process.

While many users will want to use the prebuilt libraries that we provide, we're also interested in making life as easy as possible for packagers who want to use their platform's native libraries.

If you run ccmake, you should see a STANDALONE option that determines whether the build will use your system's libraries or our prepackaged ones. Flipping this to ON should be all you need to do to perform a packager-friendly build.

For standalone builds, we'd really like to beef up the checks for system libraries so that for example cmake will fail if a required library (such as OpenJPEG) isn't installed. We welcome all patches that help out with this.

• TODO : "How to configure a standalone source code tree." (probably as a link to a new page, as this is a significantly involved task and will break up the flow of this document).

Modifying CMake Files

What to modify

'TODO - discuss structure of CMake files

Patching guidelines

We welcome your patches! We can't test on every permutation of platform, compiler, IDE, and libraries, so if you have problems that you can fix, please contribute your fixes and we'll do our best to ensure that you only have to fix problems once.

If you're sending patches in, please follow a few simple guidelines:

• Use regular context diffs. If you're attaching a patch, please try to make sure it has Unix line endings and pathnames, not Windows.
• Follow the existing coding style in the CMake files. I don't like code shouting at me, so prefer lowercase letters.
• One logical change per patch.
• Use spaces for indentation, not tabs.

See Submitting patches for more details.