Viewer 2 Microsoft Windows Builds
|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.
|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.|
- 1 Establish your programming environment
- 2 Set up your source code tree
- 3 Build the viewer with autobuild
- 4 Compile using the IDE
- 5 Iteratively fix things until the compile succeeds
- 6 Common Issues/Bugs/Glitches And Solutions
- 7 References
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.
- Obtain Visual Studio 2010 (Express is OK)
- Install Microsoft Platform & DirectX SDKs
- Run Microsoft update and keep running it until no updates are needed. This may take 6~8 iterations on older versions of windows.
- Install other development tools
- UniCode NSIS(download Unicode NSIS)
- This is the package installer used to build Setup.exe. Note: As of this writing the file is downloaded with an *.exec extension that needs renamed *.exe.
- CMake (download CMake)
- should be version 2.8.1 Kitware corrected a bug related to VS2010 at 2.8.1 and it came back in the current versions but, is due to be fixed in version 2.8.4. (and ensure any other versions aren't in your PATH environment variables)
- Cygwin (download Cygwin)
- When you run the cygwin setup utility make sure you have selected to install patchutils, flex, and bison (all located under "devel") which are not part of the default install. Do not install Cygwin Python.
- Python (download either Python.org Standard Python or ActivePython) Note: build scripts support Python 2.6, not 2.7 yet.
- TortoiseHg (download TortoiseHg) or (Mercurial Hg)
- Notepad++ (download Notepad++) (Optional)
- UniCode NSIS(download Unicode NSIS)
|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 fi 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 fi 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
- Go into that directory
hg pull http://hg.secondlife.com/viewer-development
- 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)
- Move up one level from
hg clone viewer-development VWR-nnnnn(where
nnnnnis the jira number, or clone to a name of your choosing if there is not jira number)
- Copy your
olibsfrom above into this new source tree.
Build the viewer with 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
pip install autobuild
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?))
- report your experiences, if useful, on the talk page, Talk:Viewer 2 Microsoft Windows Builds
Common Issues/Bugs/Glitches And Solutions
- Getting help:
These instructions are condensed from about a dozen previous pages of info:
- now partially incorrect
((add other references here))