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:

for VS C++ 2005

python develop.py -G VC80

or

for VS C++ 2008

python develop.py -G VC90

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 (or build-VC90) 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)

The notes in this section also apply to the 2008 express edition. --Jodiah Jensen 03:34, 29 October 2008 (UTC)

CMake and Python 2.6

If, when you run the develop.py script, you are getting an error complaining about not finding the Python Interpreter, you may need to modify the \linden\indra\cmake\Python.cmake file as follows: (thanks to Lear Cale for this code)

   find_program(PYTHON_EXECUTABLE
      NAMES python25.exe python23.exe python.exe
      NO_DEFAULT_PATH # added so that cmake does not find cygwin python
      PATHS
      [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.6\\InstallPath]       <-- add this line
      [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.5\\InstallPath]
      [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.4\\InstallPath]
      [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\2.3\\InstallPath]
      )

This should allow CMake to find your python interpreter when it needs it. (This change was needed as of version 1.21-r99587 of the source code) If you are still having the problem finding the python interpreter after this modification, try re-installing Python.

--Jodiah Jensen 03:34, 29 October 2008 (UTC)

CMake wishlist

List of issues that we +1 to get fixed

• expanded compiler flag support
• Support for Linux AMD 64 bits builds --Catherine Pfeffer 15:10, 13 September 2008 (CEST)

Python version requirement

LL supplied develop.py requires python 2.5 or later, although this wiki says python 2.3 or later works. --Alissa Sabre 18:31, 21 October 2008 (PDT)