User:Michelle2 Zenovka/cmake

How to build the viewer with cmake

This page represents some notes of mine for building the viewer via cmake. The process under linux is trivial but under windows it is slightly more involved (but not really that bad at all). If you've only ever been used to starting with a Visual Studio project file then the cmake steps may seem a little strange at first but its a great system for ensuring that radically different build environments start from the same "control" files.

As cygwin is required for a couple of operations during the building of the viewer i make use of it for svn access too. If you are more familar with unix/linux then this will feel quite at home to you, if you are use to windows it all looks a bit scary!

Prerequisites

Prerequisites for Windows

• cmake (well duh!)
• Python
• bison and flex (from cygwin)
• DirectX SDK (Microsoft DirectX SDK (November 2007))
• Quicktime SDK

Get cmake from http://www.cmake.org/HTML/Download.html Download and install the setup executable

Get python version 2.5 from http://www.python.org. (For workaround for Python 2.6, see User:Jodiah_Jensen.)

When installing cmake and python, its important to allow the commands to be addded to the system path. Both installers give an option for this towards the end of the installation. (On my system i needed to select for current user only as for all users (silently) failed to work).

Get cygwin from http://www.cygwin.com/

When you get to the package choice make sure you select bison and flex, they are under development tools.

Issues are reported with both the version of cmake supplied by cygwin and the version of python supplied by cygwin. You are recommended to install cmake and python as above.

Get DirectX SDK November 2007 from Microsoft (newer may work too) Warning 400MB+ 2007 http://www.microsoft.com/downloads/details.aspx?FamilyId=4B78A58A-E672-4B83-A28E-72B5E93BD60A&displaylang=en]

Get Quicktime SDK from Apple http://developer.apple.com/quicktime/download/

Prerequisites for Linux

For linux you will also need very similar packages to the windows build, but it is highly recommended that you install these via your distributions package management system.

Required packages (based on a minimum debian lenny install):-

• cmake
• python
• build-essential (gcc/ld/make etc)
• svn (to get latest trunk branch)
• unzip

Some header/development packages are also required (note these are the debian package names, and these packages probably depend on other packages)

Debian package names:

• libgl1-mesa-dev (Fedora: mesa-libGL-devel ?)
• libzip-dev (Fedora: zlib-devel ?)
• libfreetype6-dev
• libxft2-dev
• libxrandr-dev
• libxcursor-dev
• libglu1-mesa-dev
• libxt-dev

This list was generated by testing what the minimum packages required were to enable a successful build and link starting with a clean minimal Debian Lenny chroot.

Prerequisites for Mac

• Mac OS X 10.4 or 10.5 (required for building, sorry 10.3 users)
• XCode 2.4 or 3.0 (whichever is right for your system)
• cmake

Get a source zip/tarball release

Sorry using the cygwin prompt again because i find it easier, example with 1.22.4. Creating a folder c:\cl_1_22_4\ to work in

cd c:
mkdir sl_1_22_4
cd sl_1_22_4
wget http://secondlife.com/developers/opensource/downloads/2008/12/slviewer-src-viewer_1-22-4-r106127.zip
wget http://secondlife.com/developers/opensource/downloads/2008/12/slviewer-artwork-viewer_1-22-4-r106127.zip
wget http://secondlife.com/developers/opensource/downloads/2008/12/slviewer-win32-libs-viewer_1-22-4-r106127.zip
unzip slviewer-src*
unzip slviewer-art*
unzip slviewer-win*

Get the LATEST source from SVN

DONT DO THIS IF YOU FOLLOWED "Get a source zip/tarball release" above

Check out the source :-

svn co http://svn.secondlife.com/svn/linden/trunk trunk

Probably the best plan on Windows, if you do not have an svn client but have installed cygwin, is to go back to the cygwin setup and select the svn tools from the development group. Once these are installed you can checkout svn just like we do on unix.

Open a cygwin prompt (or for linux just at your console) and run the following commands :-

cd c:
mkdir secondlife
cd secondlife
svn co http://svn.secondlife.com/svn/linden/trunk trunk

DON'T FORGET THE ARTWORK! and what remains of the libs

Although the cmake process will now download the majority of the libraries there are still some files in the old libs package that you need to fetch.

If you are running from svn and still in your cygwin prompt/console, the easiest and quickest way to get the artwork is as follows (NOTE: on some branches, win32 asset_urls.txt are in linden/doc) -

chmod +x trunk/doc/asset_urls.txt
. trunk/doc/asset_urls.txt
wget $SLASSET_ART
wget $SLASSET_LIBS_WIN32
unzip slviewer-artwork*
unzip slviewer-*-libs*
cp linden/* trunk/ -r

For mac and linux you should use $SLASSET_LIBS_LINUXI386 or $SLASSET_LIBS_DARWIN and for linux its not unzip for the libs its tar :-

tar -xvzf slviewer-*-libs*

In fact the differences between the different libs packages now are trivial as it only contains some fonts and other trivial bits. But failure to download it (or the wrong one) can cause packaging later to fail.

In the future this section will be supplemented by a straight forward download from the usual viewer source location as well as the option of downloading the latest and greatest direct from svn trunk branch.

If you have many versions of the viewer on your machine, on Win32 it can be possible for the wrong messages.xml to get used sometimes if it isn't explicitly copied. Second Life will tend to run, but using the wrong one can cause subtle hard to trace errors. So an additional handcopy step I tend to do is cp linden/etc/messages.xml over to linden/indra/build-VC80/newview/app-settings.

Install FMOD API

At the time of writing fmod still needs to be manually downloaded and installed within the linden source tree. This is assumed you are still working from the cygwin shell or a linux terminal.

NOTE the trunk/ path at the start of all examples below is ONLY valid if you checkedout the source from SVN trunk. If you grabbed a tarball/zip it is most likely linden/ eg linden/libraries/include and NOT trunk/libraries/include. Adapt as necessary.

(linux)

wget http://www.fmod.org/index.php/release/version/fmodapi375linux.tar.gz
tar -xvzf fmodapi375linux.tar.gz
ln fmodapi375linux/api/libfmod-3.75.so trunk/libraries/i686-linux/lib_debug/
ln fmodapi375linux/api/libfmod-3.75.so trunk/libraries/i686-linux/lib_release/
ln fmodapi375linux/api/libfmod-3.75.so trunk/libraries/i686-linux/lib_release_client/
ln fmodapi375linux/api/inc/* trunk/libraries/include/

(mac)

curl --location --remote-name http://www.fmod.org/index.php/release/version/fmodapi375mac.zip 
unzip fmodapi375mac.zip 
lipo -create -output fmodapi37mac/api/lib/libfmod-universal.a\
       fmodapi37mac/api/lib/libfmod.a\
       fmodapi37mac/api/lib/libfmodx86.a
ln fmodapi375mac/api/lib/libfmod-universal.a trunk/libraries/universal-darwin/lib_debug/libfmod.a
ln fmodapi375mac/api/lib/libfmod-universal.a trunk/libraries/universal-darwin/lib_release/libfmod.a
ln fmodapi375mac/api/lib/libfmod-universal.a trunk/libraries/universal-darwin/lib_release_client/libfmod.a
ln fmodapi375mac/api/inc/* trunk/libraries/include/

(windows)

wget http://www.fmod.org/index.php/release/version/fmodapi375win.zip
unzip fmodapi385win.zip
cp fmodapi375win/api/inc/* trunk/libraries/include/
cp fmodapi375win/api/fmod.dll trunk/indra/newview
cp fmodapi375win/api/lib/fmodvc.lib trunk/libraries/i686-win32/lib/debug/
cp fmodapi375win/api/lib/fmodvc.lib trunk/libraries/i686-win32/lib/release/

Generate the project files

This is where the real fun and grace of cmake starts to take shape. Open a terminal window and go to the folder with the viewer source code. Enter the folder linden/indra/ now run the develop.py script. Probably on windows if python installed correctly you can just type "develop.py".

(It seems possible to stay with in your cygwin prompt but if this breaks on windows, open a command prompt instead)

cd trunk/indra
./develop.py configure

it may be necessary to add a -G option which selects which version of visual studio to target, possible options are :-

• VC71
• VC2003 (default)
• VC80 (VS2005)
• VC90 (VS2008)

for example

develop.py configure -G VC90

will generate project files for Visual C++ 2008

NOTE: This develop.py script now downloads the libraries that were previously in the libs zip file. This saves developers who are tracking trunk from constantly downloading them every update and only downloads updated libraries. This means on the first run develop.py will take ages download the libs and secondly if you manually want to override libs with older or newer versions it will take some dancing around (feel free to document this).

Build the viewer

Now the previous cmake process will have generated some build project files, either Unix makefiles, xcode project files or Visual Studio project files.

Visual Studio files (and xcode?) can be found under linden/indra/build-vc71 (in fact the exact path name depends on which target you have generated for). Just open the solution file .sln in that folder and build the solution in the standard way. Unix make files are found in the same location and a build can be started with a make in that directory as well. And i would guess that xcode projects are also created in the same way.

If you don't have the VSTool.exe issues below, just opening up your Visual Studio c++ will show secondlife at the top of the recent projects, ready for you to open.

It is also possible to start the build directly from the command line/console with :-

./develop.py build

On Windows (and mac?) this starts the build without using the Visual Studio/XCode environment but only using the compiler tool chain.

Problems

Boost Hell

If you use Visual Studio C++ 2008 (VC90) to build you will get boost hell. This is where the boot library will lock up solid and the viewer will not tun consuming 50-100% of CPU doing nothing. The only solutions are to use Visual Studio 2005 OR to get a newer version/rebuild boost with Visual Studio 2008. The Meerkat viewer project uses a newer version of boost that does not have trouble with VC90.

• The boost problem is being worked on. Look here for updates: VWR-9541

Express editions of Visual C++

Express editions do not have some of the extra features that VSTool.exe requires, VSTool is a little application that sets a few default project options, like which project is the startup and which build configuration to use.

FMOD

FMOD headers and libs need to be copied into the viewer build directory as stated above BUT on Windows the manifests are not currently moving the libs to the correct location post build so the application will fail to run, to resolve copy fmod.dll to indra/build-vc71/newview/debug and indra/build-vc71/newview/relwithdebinfo and indra/build-vc71/newview/release

LLKDU

This is not present in the automated libs download but is required at least on windows by the copy_win_scrips script. The file is not actually needed for the viewer to run (if present it will be used for jpeg2000 decoding in preference to Openjpeg. The solution is to remove the lines from newview/copy_win_scripts that reference llkdu and this should then allow this custom build step to run without issue

azdel slade - 2008-08-23 9:42pm SLT - I couldn't figure out where to make the edits in the solution you 
describe here. Instead, I just downloaded the latest libs from the source download page and copied 
llkdu.dll from there into my release build directory and it worked fine. once you extract the libs you 
download, it's in linden\libraries\i686-win32\lib_release 
just copy it to the same place in your build dir.

Linux

libGL.a is supplied in the linden library package and it probably should not be. To avoid linker errors please remove indra/libraries/i686-linux/release/libGL.a and indra/libraries/i686-linux/debug/libGL.a

Gentoo

If you get an undefined reference to `FT_Realloc'* from libpangoft2-1.0.so, you might have to delete even more libraries. (See here) Delete them between the ./develop.py configure and the develop.py build steps and make sure to have the listed system libraries installed.

cmake 2.6 (< 2.6.2)

cmake version 2.6.0 - 2.6.1 will fail to produce a package on linux and fail with a Make error. This does not happen with cmake 2.4 or newer cmake 2.6's

Custom builds

If you wish to do custom builds or things that develop.py just was not intended for then please have a look at User:Michelle2_Zenovka/cmake-flags