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
• Support for Linux AMD 64 bits builds --Catherine Pfeffer 15:10, 13 September 2008 (CEST)

Just a note, Python 2.6 works with develop.py, you simply have to put a link to the registry entry in the Python.cmake file. ex: (apologies for what the wiki does to the formatting)

---

e # -*- cmake -*-

set(PYTHONINTERP_FOUND)

if (WINDOWS)

 # On Windows, explicitly avoid Cygwin Python.

 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]

   [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]
   )

elseif (EXISTS /etc/debian_version)

 # On Debian and Ubuntu, avoid Python 2.4 if possible.

 find_program(PYTHON_EXECUTABLE python2.5 python2.3 python PATHS /usr/bin)

 if (PYTHON_EXECUTABLE)
   set(PYTHONINTERP_FOUND ON)
 endif (PYTHON_EXECUTABLE)

elseif (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")

 # On MAC OS X be sure to search standard locations first

 string(REPLACE ":" ";" PATH_LIST "$ENV{PATH}")
 find_program(PYTHON_EXECUTABLE
   NAMES python python25 python24 python23
   NO_DEFAULT_PATH # Avoid searching non-standard locations first
   PATHS
   /bin
   /usr/bin
   /usr/local/bin
   ${PATH_LIST}
   )

 if (PYTHON_EXECUTABLE)
   set(PYTHONINTERP_FOUND ON)
 endif (PYTHON_EXECUTABLE)

else (WINDOWS)

 include(FindPythonInterp)

endif (WINDOWS)

if (NOT PYTHON_EXECUTABLE)

 message(FATAL_ERROR "No Python interpreter found")

endif (NOT PYTHON_EXECUTABLE)

mark_as_advanced(PYTHON_EXECUTABLE)

---