User:Michelle2 Zenovka

From Second Life Wiki
Jump to navigation Jump to search
View the issues Michelle2 Zenovka has filed at jira.secondlife.com

CMAKE

My various cmake notes

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 back to: User:Michelle2_Zenovka/cmake

Intro

Normaly develop.py will bootstrap the actual cmake process for you, but you may wish to override certain operations. The Debian build for example does not use develop.py but calls cmake directly.

The typical invocation of cmake will look like the following :- 

cmake -G "Visual Studio 7 .NET 2003" -DUNATTENDED:BOOl=FALSE -DSTANDALONE:BOOL=FALSE "" "c:\\secondlife\\Release\\release\\indra

Its also possible to specify variables to be set when calling develop.py with the configure parameter eg :- 

develop.py configure -DMYVARIABLE:BOOL=TRUE

Generators

The -G option of cmake specifies the generator to be used (the target to build project file for). The Secondlife viewer cmake currently supports the following targets :-

Windows

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

Linuxoids

  • Unix Makefiles (default)
  • KDevelop3

Mac

  • Xcode
  • Unix Makefiles (default) (WARNING: you probably don't want makefiles, and need to specify -G Xcode to avoid them!)

Variables

cmake variables are passed on the command line with the -D option, followed by the variable name, a seperation colon, the type of variable then =value for example :- 

-DSTANDALONE:BOOL=FALSE

Variable name STANDALONE

Type BOOL

value FALSE

There are a whole bunch of useful variables that can be set to control the cmake building process, some of these are listed below (feel free to add more) Most of the others are automaticly generated based on trying to find locations of required libraries. The full list of setable ones can be seen in indra/CMakeCache.txt after running cmake for the first time

  • CMakeCache.txt location may differ: for Linux, looks like it's indra/viewer-linux-i686-relwithdebinfo/CMakeCache.txt


STANDALONE BOOL Sets the build to standalone mode, if enabled the build will try to use system provided libraries instead of the ones from the libs tarball.
UNATTENDED BOOL Normally set to false, Internal option for Linden Labs building???
INSTALL BOOL Enable Unix install target
APP_BINARY_DIR STRING (Unix install target) Installation directory for the main secondlife-bin
APP_SHARE_DIR STRING (Unix install target) Installation directory for read-only data files
BINARY_NAME STRING Replacement name for secondlife-bin executable
FMOD_SDK_DIR STRING Set location of FMOD API files to save copying into build tree
MOZLIB BOOL Enable embedded web browsing and html content in world (if you are building standalone and using a llmozlib2 package this needs enabling as its excluded in a standalone build otherwise)
OPENAL BOOL Enable OpenAL for sound, only works with openAL patch from jira
CMAKE_BUILD_TYPE STRING 'No help, variable specified on the command line' (build type?)

The Debian Way

The debian rules Makefile, invokes cmake as :- 

cmake -DUNATTENDED:BOOl=FALSE -DSTANDALONE:BOOL=TRUE \
       -DCMAKE_BUILD_TYPE:STRING=Release-DSERVER:BOOL=FALSE \
       -DVIEWER:BOOL=TRUE -DMOZLIB:BOOL=true -DINSTALL:BOOL=TRUE \
       -DAPP_SHARE_DIR:STRING=/usr/share/omvviewer/ \
       -DAPP_BINARY_DIR:STRING=/usr/games/ \
       -DCMAKE_INSTALL_PREFIX:STRING=debian/ \
       -DBINARY_NAME:STRING=omvviewer \
       -DOPENAL:BOOL=TRUE \
Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Michelle2_Zenovka&oldid=81365"