Viewer 2 Microsoft Windows Builds

From Second Life Wiki
Revision as of 08:54, 28 March 2011 by Alain Linden (Talk | contribs)

Jump to: navigation, search
KBwarning.png Work in progress These instructions are not yet complete or debugged as of March 22, 2011.

When finished, we hope this page will constitute a complete recipe for compiling viewer 2 from source on a Windows machine.

Philosophy: to keep it brief, this page should only include steps we KNOW ARE NEEDED, not random hints. Extra details or open issues can go on the talk page.

KBnote.png Note: Following this recipe will probably take 6 to 12 hours of wall-clock time, and 2 to 6 hours of your time, if you're starting from a fresh Windows XP/Vista/7 system.

Establish your programming environment

This is needed for compiling any viewer based on the LL open source code, but only needs to be done once.

  1. Obtain Visual Studio 2010 (Express is OK)
    Click here to download Visual C++ Express - current version is VS2010
  2. Install Microsoft Platform & DirectX SDKs
    Download and install Windows SDK for Windows 7 and .NET Framework 4 (ISO) or Windows SDK for Windows 7 and .NET Framework 4 (Web Install) and
    Download and install DirectX SDK (June 2010)
  3. Run Microsoft update and keep running it until no updates are needed. This may take 6~8 iterations on older versions of windows.
  4. Install other development tools
KBnote.png Note: If the installer for a particular package does not update your PATH environment setting you will have to do this manually.

Additionally it is recommended that you make the following changes to your Cygwin installation:

  • Override cygwin's python:
 if [ -f /usr/bin/python.exe ]; then
   mv /usr/bin/python.exe /usr/bin/cygwin-python.exe
 cp /cygdrive/c/Python26/python.exe /usr/bin/python.exe
  • Override cygwin's mercurial:
 if [ -f /usr/bin/hg.exe ]; then
   mv /usr/bin/hg.exe /usr/bin/cygwin-hg.exe
 cp /cygdrive/c/Program\ Files/Mercurial/hg.exe /usr/bin/hg.exe

The native Cygwin python and hg do not work very well and should be avoided.

Set up your source code tree

Plan your directory structure ahead of time. If you are going to be producing changes or patches you will be cloning a copy of an unaltered source code tree for every change or patch you make, so you might want to have all this work stored in it's own directory.

To get a copy of the source code tree:

  • Open up a DOS/Command window
  • Make a directory to contain it (it is strongly suggested to name it viewer-development)
  • Go into that directory
  • Do hg init
  • Do hg pull
  • Example: ((specific snapshot example TBD))

Let's say some time has gone by since you have performed the previous steps and now you want to develop a change or work on a jira. You will

  • Go into viewer-development (or whatever you named the master source tree copy)
  • Do hg pull
  • Do hg update
  • Move up one level from viewer-development
  • Do hg clone viewer-development VWR-nnnnn (where nnnnn is the jira number, or clone to a name of your choosing if there is not jira number)
  • Copy your olibs from above into this new source tree.

Build the viewer with autobuild

Install autobuild

If you haven't done so already, install autoubuild. Full instructions can be found on the Autobuild page, but most users may simply use

 easy_install autobuild


pip install autobuild

to install.

Build a desired configuration

With a properly configured developer machine (see compiling), building the viewer with autobuild is as simple as invoking

 autobuild build -c [CONFIGURATION]

where CONFIGURATION stands for the build configuration you would like to build. The build configurations defined in the viewer's autobuild.xml file follow some simple conventions which we describe below. As a developer you should choose the appropriate build configuration for your needs. After a build has completed, the resulting product will be found in the build directory named build-* where the * is wildcard representing the platform dependent part of the name.

Developers who wish to build a viewer with an IDE don't have to do a full command line build. Using

 autobuild configure -c [CONFIGURATION]

Will install any dependencies (if the build configuration uses them) and construct an appropriate project or solution file (.xcodeproj for mac and .sln for windows) inside the build directory.

Base build configurations

There are three basic types of build configurations which are used to vary the debugability of the resulting build versus optimization. These configurations are:

  • Debug — unoptomized with debugging information.
  • RelWithDebInfo — optomized but with debugging information.
  • Release — optimized with no debug information.

Debug will result in a slow client but is the easiest to use with a debugger. RelWithDebInfo is significantly faster and is often easy to debug, but code optimizations may occasionally make tracking program flow in a debugger challenging. Release is used for building a shipping version of the viewer.

Build variations for open source developers

The unmodified build configuraitons defined in the previous section are configured for use by Linden developers and may require access to installables which are not publicly available. For open source developers two variations are provided to support development by third parties using the following prefixes:

  • OpenSource — build a viewer using only publicly distributed installables.
  • OpenSourceStandAlone — build a viewer without using any installable packages provided by Linden.
    Developers will need to install any 3rd party dependencies manually.

To build an open source configuration choose a build configuration which is a concatonation of one of the two above prefixes with a base configuraiton name. For example to build a stand alone viewer with release optimization including debug information run

autobuild build -c OpenSourceStandAloneRelWithDebInfo

Compile using the IDE

Follow the steps for configuring outlined in Build Viewer With Autobuild. This will create the build-vc100 directory at the root of the source tree which contains the SecondLife.sln solution file. The solution is fully configured and ready to be built.

Iteratively fix things until the compile succeeds

((TBD - add any fixup steps here. e.g. does fmod375.dll need to be moved into RelWithDbgInfo at this step?))

Common Issues/Bugs/Glitches And Solutions

  • Getting help:
    • Subscribe to OpenSource-Dev Mailing List (subscribe) and post your question there.
    • For faster response, find a free IRC client program and join #opensl on freenode, the general open source viewer discussion and development channel. Hopefully a helpful person is online when you ask your question.


These instructions are condensed from about a dozen previous pages of info:

((add other references here))