Difference between revisions of "CMake"
(Update links to cmake-9 and script name to develo.py) |
|||
| Line 1: | Line 1: | ||
= What's this about? = | = What's this about? = | ||
We | We recently (June 2008) switched to [http://www.cmake.org/ CMake] for building the Second Life viewer. | ||
== What does CMake buy us? == | == What does CMake buy us? == | ||
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 | 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. | 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. | ||
| Line 33: | Line 24: | ||
|- | |- | ||
| Linux | | Linux | ||
| Fedora | | Fedora 9 | ||
| x86_64 | | x86_64 | ||
| gcc 4. | | gcc 4.3.0 | ||
| standalone | |||
|- | |||
| Linux | |||
| Ubuntu 8.04 | |||
| i686 | |||
| gcc 4.2.3 | |||
| standalone | | standalone | ||
|- | |- | ||
| Line 54: | Line 51: | ||
| i386 | | i386 | ||
| VS 2005 | | VS 2005 | ||
| prebuilt libraries | |||
|- | |||
| Windows | |||
| XP | |||
| i386 | |||
| VS 2008 | |||
| prebuilt libraries | | prebuilt libraries | ||
|} | |} | ||
| Line 61: | Line 64: | ||
= Performing a build with CMake = | = Performing a build with CMake = | ||
If you want to try a CMake-powered build, it helps to already be familiar with our [[Get source and compile | | If you want to try a CMake-powered build, it helps to already be familiar with our [[Get source and compile | build process]]. | ||
First of all, you'll need to [http://www.cmake.org/HTML/Download.html download CMake], and install it. On Linux distros, it's usually available as a native package. On Windows and OS X, just use the prebuilt binaries. | First of all, you'll need to [http://www.cmake.org/HTML/Download.html download CMake], and install it. On Linux distros, it's usually available as a native package. On Windows and OS X, just use the prebuilt binaries. | ||
<b>Note</b>: we do not yet support CMake 2.6.0. Please use CMake 2.4.8 instead. | |||
< | |||
</ | |||
== Configuring your tree == | == Configuring your tree == | ||
| Line 78: | Line 74: | ||
Before you first run a build, you'll need to configure things. There's an <code>indra/develop.py</code> script that will do this for you. Simply run it from the command line and it will create a reasonably sane default configuration. | Before you first run a build, you'll need to configure things. There's an <code>indra/develop.py</code> script that will do this for you. Simply run it from the command line and it will create a reasonably sane default configuration. | ||
In the CMake world, we | In the CMake world, we keep source and object files separate. The <code>develop.py</code> script will create and populate a build directory for you. On Linux, this will be named <code>viewer-linux-i686</code>. On OS X, it will be <code>build-darwin-universal</code>. On Windows, it will be <code>build-vc71</code> or <code>build-vc80</code>. | ||
== What to expect == | == What to expect == | ||
| Line 95: | Line 91: | ||
On OS X, it will be here by default: | On OS X, it will be here by default: | ||
<pre> | <pre> | ||
build-darwin- | build-darwin-universal/newview/RelWithDebInfo/Second Life.app | ||
</pre> | </pre> | ||
If you change the kind of build you use, the intermediate directory will also change, e.g. from <code>RelWithDebInfo</code> to <code>Release</code>. | If you change the kind of build you use, the intermediate directory will also change, e.g. from <code>RelWithDebInfo</code> to <code>Release</code>. | ||
On Windows, the built viewer ought | On Windows, the built viewer ought to run from VS2005. | ||
= Prebuilt libraries vs. standalone builds = | = Prebuilt libraries vs. standalone builds = | ||
| Line 118: | Line 114: | ||
* One logical change per patch. | * One logical change per patch. | ||
* Use spaces for indentation, not tabs. | * Use spaces for indentation, not tabs. | ||
Please also see the (user contributed) instructions at [http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake] | Please also see the (user contributed) instructions at [http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake] | ||
Revision as of 15:03, 2 June 2008
What's this about?
We recently (June 2008) switched to CMake for building the Second Life viewer.
What does CMake buy us?
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.
What have we tested?
We've performed test build-and-run cycles on the following platforms.
| Linux | Debian sarge | i386 | gcc 3.4 | prebuilt libraries |
| Linux | Fedora 9 | x86_64 | gcc 4.3.0 | standalone |
| Linux | Ubuntu 8.04 | i686 | gcc 4.2.3 | standalone |
| Mac OS X | 10.5 (Leopard) | i386 | Xcode 3.0 | prebuilt libraries |
| Mac OS X | 10.5 | PowerPC | Xcode 3.0 | prebuilt libraries |
| Windows | XP | i386 | VS 2005 | prebuilt libraries |
| Windows | XP | i386 | VS 2008 | prebuilt libraries |
Not every platform has been equally tested, and not every feature is fully functional. Please help us to track problems by reporting any trouble you run into.
Performing a build with CMake
If you want to try a CMake-powered build, it helps to already be familiar with our build process.
First of all, you'll need to download CMake, and install it. On Linux distros, it's usually available as a native package. On Windows and OS X, just use the prebuilt binaries.
Note: we do not yet support CMake 2.6.0. Please use CMake 2.4.8 instead.
Configuring your tree
Before you first run a build, you'll need to configure things. There's an indra/develop.py script that will do this for you. Simply run it from the command line and it will create a reasonably sane default configuration.
In the CMake world, we keep source and object files separate. The develop.py script will create and populate a build directory for you. On Linux, this will be named viewer-linux-i686. On OS X, it will be build-darwin-universal. On Windows, it will be build-vc71 or build-vc80.
What to expect
Running develop.py does not actually start a build. It just generates the makefiles, project files, or whatever that you'll need. After you're done, you'll have a top-level makefile or project file in your build directory. Run make or load it into your IDE, and away you go!
In principle, your build should run to completion. If you run into any problems, please report them. Better yet, if you can fix them and supply patches, we'd be thrilled! Please follow the usual contribution agreement guidelines.
Where's the built viewer?
The location of the newly built viewer depends on your platform. On Linux, it'll be here:
build-linux-i686/newview/packaged
On OS X, it will be here by default:
build-darwin-universal/newview/RelWithDebInfo/Second Life.app
If you change the kind of build you use, the intermediate directory will also change, e.g. from RelWithDebInfo to Release.
On Windows, the built viewer ought to run from VS2005.
Prebuilt libraries vs. standalone builds
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.
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.
Please also see the (user contributed) instructions at http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake