Difference between revisions of "Talk:CMake"

From Second Life Wiki
Jump to navigation Jump to search
 
(16 intermediate revisions by 7 users not shown)
Line 18: Line 18:
''CMake Error: Could not find APRUTIL library''
''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.
* 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.
=== Comment ===
I do not use the --standalone option, even for compiling standalone viewers since this will fail depending on what libraries versions exist on your system (for example, with Mandriva 2009.0, I have db v4.6 and not db v4.2 as required by the viewer, and forcing a compilation with db 4.6 results in a non-functional viewer).
<br />Instead, I compile a release viewer but I replace the pre-built libraries with the compatible libraries of my system. To do this easily, I wrote a script: [[Building_the_viewer_with_CMake/cmake-SL_script|cmake-SL]]. The result is a mostly standalone viewer (for example, in Mandriva 2009.0, I keep the pre-built DB4.2 and APR libraries).
<br />[[User:Henri Beauchamp|Henri Beauchamp]] 17:24, 1 December 2008 (UTC)


== CMake and Visual Studio C++ 2005 Express Edition ==
== CMake and Visual Studio C++ 2005 Express Edition ==
Line 27: Line 33:
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:
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
for VS C++ 2005
 
  <code>python develop.py -G VC80</code>
 
 
or
 
for VS C++ 2008
 
<code>python develop.py -G VC90</code>
 


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:
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:
Line 36: Line 52:


Don't worry about this, the solution files have been created successfully.
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.
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.  
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.  
Line 49: Line 65:
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. --[[User:Nexii Malthus|Nexii Malthus]] 13:16, 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. --[[User:Nexii Malthus|Nexii Malthus]] 13:16, 7 September 2008 (PDT)


== CMake wishlist ==
I had issues after compiling the viewer where I didn't hear any sound. In order to activate sound I ran Cmake, marked the box to activate FMOD and recompiled the viewer. This action enabled sound, thanks to Michelle Zenovka for pointing this out.
 
The notes in this section also apply to the 2008 express edition.
 
I posted the steps I took to compile the source using 2008 Express here: [https://wiki.secondlife.com/wiki/User:Jodiah_Jensen How I Compiled SL Source w/ VC++ 2008 Express Edition ]
 
--[[User:Jodiah Jensen|Jodiah Jensen]] 03:34, 29 October 2008 (UTC)
 
== CMake and Python 2.7 ==
First, make sure you are using the WINDOWS versions of CMake and Python, do not use the CMake and Python versions included with Cygwin.
 
You can get CMake for win32 here: http://www.cmake.org/files/v2.4/cmake-2.4.8-win32-x86.exe
 
You can get Python here: http://www.python.org/download/
 


List of issues that we +1 to get fixed
If, when you run the develop.py script, you are getting an error complaining about not finding the Python Interpreter ('''''"CMake Error: No Python interpreter found"'''''), you may need to modify the \linden\indra\cmake\Python.cmake file as follows: (thanks to [https://wiki.secondlife.com/wiki/User:Lear_Cale Lear Cale] for this code)


[http://public.kitware.com/Bug/view.php?id=7643 expanded compiler flag support]
    find_program(PYTHON_EXECUTABLE
*  Support for Linux AMD 64 bits builds --[[User:Catherine Pfeffer|Catherine Pfeffer]] 15:10, 13 September 2008 (CEST)
      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.7\\InstallPath]''' <--- ADD THIS Python has since updated from 2.6
      [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]
      )


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:
This should allow CMake to find your python interpreter when it needs it.
(apologies for what the wiki does to the formatting)
(This change was needed as of version 1-21-r99587 of the source code)
---------------
e # -*- cmake -*-


set(PYTHONINTERP_FOUND)
If you are still having the problem finding the python interpreter after this modification, try re-installing Python.


if (WINDOWS)
--[[User:Jodiah Jensen|Jodiah Jensen]] 03:34, 29 October 2008 (UTC)
  # On Windows, explicitly avoid Cygwin Python.


  find_program(PYTHON_EXECUTABLE
'''GOOD NEWS:'''
    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)
''"...saw your Python 2.6 tweak, and nudged the dev team to pick up the change, so that it should work in the future without needing that edit (it'll be in the next trunk rev, and will show up in roughly the 1.23 timeframe)."''-- [[User:Rob Linden|Rob Linden]] 16:23, 29 October 2008 (UTC)


  if (PYTHON_EXECUTABLE)
== CMake wishlist ==
    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}")
List of issues that we +1 to get fixed
  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)
*  [http://public.kitware.com/Bug/view.php?id=7643 expanded compiler flag support]
    set(PYTHONINTERP_FOUND ON)
*  Support for Linux AMD 64 bits builds --[[User:Catherine Pfeffer|Catherine Pfeffer]] 15:10, 13 September 2008 (CEST)
  endif (PYTHON_EXECUTABLE)
else (WINDOWS)
  include(FindPythonInterp)
endif (WINDOWS)


if (NOT PYTHON_EXECUTABLE)
== Python version requirement ==
  message(FATAL_ERROR "No Python interpreter found")
endif (NOT PYTHON_EXECUTABLE)


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

Latest revision as of 11:54, 3 September 2010

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.

Comment

I do not use the --standalone option, even for compiling standalone viewers since this will fail depending on what libraries versions exist on your system (for example, with Mandriva 2009.0, I have db v4.6 and not db v4.2 as required by the viewer, and forcing a compilation with db 4.6 results in a non-functional viewer).
Instead, I compile a release viewer but I replace the pre-built libraries with the compatible libraries of my system. To do this easily, I wrote a script: cmake-SL. The result is a mostly standalone viewer (for example, in Mandriva 2009.0, I keep the pre-built DB4.2 and APR libraries).
Henri Beauchamp 17:24, 1 December 2008 (UTC)

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)

I had issues after compiling the viewer where I didn't hear any sound. In order to activate sound I ran Cmake, marked the box to activate FMOD and recompiled the viewer. This action enabled sound, thanks to Michelle Zenovka for pointing this out.

The notes in this section also apply to the 2008 express edition.

I posted the steps I took to compile the source using 2008 Express here: How I Compiled SL Source w/ VC++ 2008 Express Edition

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

CMake and Python 2.7

First, make sure you are using the WINDOWS versions of CMake and Python, do not use the CMake and Python versions included with Cygwin.

You can get CMake for win32 here: http://www.cmake.org/files/v2.4/cmake-2.4.8-win32-x86.exe

You can get Python here: http://www.python.org/download/


If, when you run the develop.py script, you are getting an error complaining about not finding the Python Interpreter ("CMake Error: No Python interpreter found"), 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.7\\InstallPath] <--- ADD THIS Python has since updated from 2.6
      [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]
      )

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)

GOOD NEWS:

"...saw your Python 2.6 tweak, and nudged the dev team to pick up the change, so that it should work in the future without needing that edit (it'll be in the next trunk rev, and will show up in roughly the 1.23 timeframe)."-- Rob Linden 16:23, 29 October 2008 (UTC)

CMake wishlist

List of issues that we +1 to get fixed

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)