Talk:CMake

Issues when compiling a standalone Linux viewer

This is on Linux Ubuntu Hardy 8.04.--oobscure 13:20, 1 September 2008 (PDT)

With 'standalone Linux' I mean using system libraries instead of libraries provided by Linden Lab as mentioned at CMake#Prebuilt_libraries_vs._standalone_builds. This can be done running the develop.py script with the '--standalone' option:

./develop.py --standalone

Error message

• possible solution

CMake Error: Could not find BerkeleyDB library

• sudo apt-get install libdb-dev

CMake Error: Could not find APR library

• sudo apt-get install libapr1-dev

CMake Error: Could not find APRUTIL library

• we should probably install libaprutil1-dev or libaprutil1.0-dev, but this doesn't work on my system (Ubuntu 8.04) because of dependencies problems that apparently can't easily solved.

CMake and Visual Studio C++ 2005 Express Edition

For me, the process of building the client wasn't as straightforward as the documentation made it seem. Here's some tips that will hopefully prevent the next person from experiencing the same frustrations.

I made the mistake of copying everything the Compiling_the_viewer_(MSVS2005) page told me to copy. You *only* need to do the fmod section (3.2.1). After doing that, ignore the rest of that page.

First off, getting develop.py to work: You need to specify your visual c++ version explicitly. Without any arguments specifying the version, develop.py will complain and error out. So from the command line:

python develop.py -G VC80

As far as I can tell, at the very end of the environment setup develop.py attempts to run a utility called vstool. vstool doesn't like the Express Edition, so the last few messages it will print are:

Value cannot be null.
Parameter name: type
Quitting to do error opening: C:\...\linden\indra\build-VC80\SecondLife.sln

Don't worry about this, the solution files have been created successfully. develop.py should have created a build-VC80 folder. In it you'll find SecondLife.sln. Open it, but before you build you have to do a few things. In Visual Studio, you'll need to set secondlife-bin as the StartUp project. Do this by right clicking the secondlife-bin project, then selecting Set as StartUp Project.

Under the copy-win-libs project, in the CMake Rules folder, delete all the llkdu.dll.rule files. This will force the client to fall back on openjpeg, which is good because I have no clue where to get llkdu.dll. The one in C:\Program Files\Second Life will only cause you pain and misery, so don't try it.

Select the secondlife-bin project. In the drop-down to the right of the green play button at the top, select RelWithDebInfo then click the play button. This will build a Release viewer that has extra debug information printed to the console (and debug symbols too?). Build it. It will fail, complaining about not being able to find fmod.dll.

This is because it's looking in the wrong place by default. Right click the secondlife-bin project, and click Properties. In the Property Pages dialog that appears, under Configuration Properties, click Debugging. Change the working directory to wherever you put linden\indra\newview. Try building again, and it should work!

Hope this helps. --Christopher Omega 12:51, 7 September 2008 (PDT)

Er, well the llKdu.dll worked perfectly fine for me, your problem is that you grabbed it from the wrong client build, I can't remember from which one it was, but it was either the RC or the PG Mono client. --Nexii Malthus 13:16, 7 September 2008 (PDT)

CMake wishlist

List of issues that we +1 to get fixed

• expanded compiler flag support