- 1 How to build the viewer with cmake
- 1.1 Prerequisites
- 1.2 Get the source
- 1.3 Install FMOD API
- 1.4 Generate the project files
- 1.5 Build the viewer
- 1.6 Problems
- 1.7 Custom builds
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 for Windows
- cmake (well duh!)
- bison and flex (from cygwin)
- DirectX SDK (Microsoft DirectX SDK (November 2007))
- Quicktime SDK
- openssl SDK
Get cmake from http://www.cmake.org/HTML/Download.html Download and install the setup executable
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.
Get DirectX SDK November 2007 from Microsoft 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/
I think this is now with the viewer code and shipped, Please double check me!
Not sure why this is not packaged with the viewer. Probably license issues as OpenSSL can be troublesome WRT licenses and compatibility with other licenses. Some windows packages are available which may be a better solution. Work to do
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):-
- build-essential (gcc/ld/make etc)
- svn (to get latest trunk branch)
Some header/development packages are also required (note these are the debian package names, and these packages probably depend on other packages)
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)
Get the source
At the time of writing the source is only available via SVN. cmake based viewer builds are in the trunk branch so it should be in a released zip ball soon and is expected to start shipping with the 1.21 RCs
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.
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/
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/libfmod-universal.a trunk/libraries/universal-darwin/lib_debug/libfmod.a ln fmodapi375mac/api/libfmod-universal.a trunk/libraries/universal-darwin/lib_release/libfmod.a ln fmodapi375mac/api/libfmod-universal.a trunk/libraries/universal-darwin/lib_release_client/libfmod.a ln fmodapi375mac/api/inc/* trunk/libraries/include/
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 :-
- VC2003 (default)
- VC80 (VS2005)
- VC90 (VS2008)
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 :-
On Windows (and mac?) this starts the build without using the Visual Studio/XCode environment but only using the compiler tool chain.
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.
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 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
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.
ligGL.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
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
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