Difference between revisions of "CMake"

From Second Life Wiki
Jump to navigation Jump to search
m
 
(64 intermediate revisions by 16 users not shown)
Line 1: Line 1:
= Building the viewer using CMake =
CMake is a system for generating per-platform build files.  Visit [http://cmake.org cmake.org] for general information about CMake.


We're experimenting with the possibility of switching to [http://www.cmake.org/ CMake] for building the Second Life viewer.
Linden Lab switched to CMake for building the Second Life viewer (starting with version 1.21); we are currently using version 2.8.10.2


== Why change what we're doing?
= Introduction to CMake =


Our current build system is unsatisfactory in several respects.
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.


Within Linden Lab, we use different tools on each platform: [http://www.scons.org/ scons] on Linux, Visual Studio 2003 on Windows, and XCode on OS X.
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.
* Any time we add or rename a source file, updating the various build instructions is painful.
 
* We can't easily stay up to date with newer tools, such as Visual Studio 2005 or 2008.
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 <code>cmake</code> once.  After that, <code>make</code> or your IDE should keep the CMake files and its own project files in sync for you.
* Merging changes to the project files used by XCode and Visual Studio is a nightmare.
 
= Performing a build with CMake =


== What does CMake buy us? ==
Our builds are now managed one layer further out then CMake, using [[Autobuild]]; starting there is recommended.


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.
Per platform build instructions for CMake-based builds of the Second Life viewer are available for these platforms:
* [[Microsoft Windows Builds|Microsoft Windows]]
* [[Compiling the viewer (Mac OS X)|Mac OS X]]
* [[Compiling the viewer (Linux)|Linux]]


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.


== What are the disadvantages of CMake? ==
= Modifying CMake Files =


The CMake configuration language is weird and ugly.
== What to modify ==


The documentation is poor.  This is a much bigger problem for new projects than ones that already have CMake in place.  We've already survived the early "WTF?" stages; it's much easier to hack on existing CMake files than it is to create new ones from scratch.
'''TODO'' - discuss structure of CMake files


= Experimenting with CMake =
= Patching guidelines =


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.
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.


These are Linux/Mac instructionsThe Windows instructions are presumably similar, except you wave your mouse around instead of running commands.
If you're sending patches in, please follow a few simple guidelines:
* Follow the existing coding style in the CMake filesI don't like code shouting at me, so prefer lowercase letters.
* One logical change per patch.
* Use spaces for indentation, not tabs.


Check out a copy of the viewer cmake branch:
See [[Submitting patches]] for more details.
<pre>
svn co http://svn.secondlife.com/svn/linden/branches/cmake
</pre>
Create a build directory:
<pre>
mkdir mybuild
</pre>
Go into your build directory, and run <code>cmake</code> or <code>ccmake</code> in there, pointing it at the parent directory.  If you want to generate a makefile for use by [http://www.gnu.org/software/make/ GNU Make], the defaults will work.
<pre>
cmake ..
</pre>
If you're on a Mac and want to use XCode, use this command instead.
<pre>
cmake -G XCode ..
</pre>


This does <i>not</i> run 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 <code>make</code> or load it into your IDE, and away you go!
[[Category:Open Source Portal]]
[[Category:Compiling viewer]]

Latest revision as of 09:35, 13 February 2013

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); we are currently using version 2.8.10.2

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

Our builds are now managed one layer further out then CMake, using Autobuild; starting there is recommended.

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


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:

  • 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.