Difference between revisions of "Viewer 2 Microsoft Windows Builds"

From Second Life Wiki
Jump to navigation Jump to search
(→‎Configure VS2010: use $(WindowsSdkDir) instead of %ProgramFiles%\Microsoft SDKs\Windows\v7.1 so we don't depend on a specific SDK version)
(→‎Configure VS2010: use $(DXSDK_DIR), so we can get rid of almost all red text)
Line 67: Line 67:


  $(ExecutablePath)
  $(ExecutablePath)
  %ProgramFiles<span style="color:red;">(x86)</span>%\Microsoft DirectX SDK (June 2010)
  $(DXSDK_DIR)
  $(WindowsSdkDir)\Bin
  $(WindowsSdkDir)\Bin
  C:\Python26
  C:\Python26
Line 85: Line 85:
  $(WindowsSdkDir)\Samples\winui\tsf\tsfapp
  $(WindowsSdkDir)\Samples\winui\tsf\tsfapp
  Note: The above line may no longer be required
  Note: The above line may no longer be required
  %ProgramFiles<span style="color:red;">(x86)</span>%\Microsoft DirectX SDK (June 2010)\Include
  $(DXSDK_DIR)\Include


[[File:VS2010_Include_Directories.PNG|100px]]
[[File:VS2010_Include_Directories.PNG|100px]]
Line 94: Line 94:


  $(WindowsSdkDir)\Lib
  $(WindowsSdkDir)\Lib
  %ProgramFiles<span style="color:red;">(x86)</span>%\Microsoft DirectX SDK (June 2010)
  $(DXSDK_DIR)


[[File:VS2010_Library_Directories_reva.PNG|100px]]
[[File:VS2010_Library_Directories_reva.PNG|100px]]

Revision as of 03:01, 1 June 2011

KBwarning.png Work in progress These instructions are not yet complete or debugged as of May 31, 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. Install Visual Studio 2010 (Express is okay)
  2. Install Windows SDK for Windows 7 and .NET Framework 4 (ISO) or Windows SDK for Windows 7 and .NET Framework 4 (Web Install)
  3. Run Microsoft Update, and keep running it until no updates are needed. This may take 6~8 iterations on older versions of windows.
    • Note: For windows Vista and Windows 7, you need to select "Get updates from other Microsoft products." to get the updates for Visual Studio.
    • For Windows XP, use the provided link above to go to update.microsoft.com and not update.windows.com that is the default update service for XP.
  4. Install DirectX SDK (June 2010)
  5. Install other development tools
    • CMake
      This should be version 2.8.4 (or above in the 2.8.x series). Ensure that any older versions aren't in your PATH environment variables.
    • Cygwin
      When you run the cygwin setup utility make sure you have selected to install patchutils, flex, bison (all located under "devel"), curl (under "Web"), and unzip (under "Archives"), which are not part of the default install. Do not install Cygwin Python or Mercurial. You won't need to use the Cygwin shell for anything; just have the binaries accessible to the regular command line via your PATH.
    • Python (either Standard Python or ActivePython)
      Note: Version 2.7.1 has been reported to work with the build scripts.
    • Mercurial (either TortoiseHg or Mercurial Hg)
    • Unicode NSIS (Nullsoft Scriptable Install System)
      This is the package installer used to build Setup.exe.
    • (optional) Notepad++
      You need to use an editor that conforms to the Coding Standard. In particular, you must not check in files with DOS line endings except in very limited circumstances; see How to avoid DOS line endings in Windows 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.

Set up Autobuild

  • Install Autobuild
  • Modify your path statement to include the autobuild \bin directory

Configure VS2010

While you may choose to use autobuild for all your compiling you still need to establish certain settings internal to VS2010.

Start the IDE

Navigate to Tools > Options > Projects and Solutions > Build and Run and set "maximum number of parallel projects builds" to 1.

Check Tools > Settings > Expert Settings.

You need to set a number of paths.

Open an existing project or make a New Project. At this point it doesn't need to be a Second Life solution just any project.

At the bottom on the Solution Explorer you will see three tabs. Click the one on the right "Property Manager" though the name may be somewhat truncated.

Click on the + to open the project and then on one of the +'s just revealed.

Right click on Microsoft.Cpp.Win32.user.

Pick Properties > VC++ Directories.

This is where the build environment is pulled together into a functional VC2010 build system and also where much hand wringing, hair pulling, and fist pounding frustration takes place.

KBnote.png Note: Below, text in red is for 64-bit variants of Windows. If you use a 32-bit Windows, remove the red text.

Set Executable Directories to:

$(ExecutablePath)
$(DXSDK_DIR)
$(WindowsSdkDir)\Bin
C:\Python26
%ProgramFiles(x86)%\NSIS\Unicode
C:\cygwin\bin
$(SystemRoot)
$(SystemRoot)\System32
$(SystemRoot)\System32\wbem

VS2010 Executable Directories.PNG 64 bit example image

Set Include Directories to:

$(WindowsSdkDir)\Include
$(WindowsSdkDir)\Include\gl
$(WindowsSdkDir)\Samples\winui\tsf\tsfapp
Note: The above line may no longer be required
$(DXSDK_DIR)\Include

VS2010 Include Directories.PNG 64 bit example image


Set Library Directories to:

$(WindowsSdkDir)\Lib
$(DXSDK_DIR)

VS2010 Library Directories reva.PNG 64 bit example image

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 your build tree (it is strongly suggested to name it viewer-development). Do not have any spaces in this path.
  • Go into that directory
  • Do hg init
  • Do hg pull http://hg.secondlife.com/viewer-development

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)

Prepare third party libraries

Most third party libraries needed to build the viewer will be automatically downloaded for you and installed into the build directory within your source tree during the configuration step below. Some few need to be manually set up, though, when using an open source developer configuration (ReleaseOS, RelWithDebInfoOS or DebugOS)

KBnote.png Note: If you are a Linden Lab employee or otherwise have legitimate access to s3-proxy.lindenlab.com, all third party libraries should be automatically downloaded and installed for you, so you may ignore this section completely. (In that case, make sure to use one of the LL-internal configurations, i.e. one without the OS-suffix in its name.)

Fmod

Create a directory for the 3p-fmod repository and clone it:

hg clone https://bitbucket.org/lindenlab/3p-fmod

CD into the 3p-fmod directory you created and build it:

autobuild build --all

Package the results:

autobuild package 

Now update autobuild with the filename and hash just displayed.

CD to the directory where you cloned viewer-development

copy autobuild.xml to my_autobuild.xml

Do:

set AUTOBUILD_CONFIG_FILE=my_autobuild.xml
autobuild installables edit fmod platform=windows hash=<hash> url=file:///<fmod-filespec>

Example:

autobuild installables edit fmod platform=windows hash=0f196f00e7dff49f22252efb68525658 url=file:///C:/3p-fmod/fmod-3.75-windows-20110531.tar.bz2
KBnote.png Note: Having to copy autobuild.xml and modify the copy from within a cloned repository is a lot of work for every repository you make, but this is the only way to guarantee you pick up upstream changes to autobuild.xml and do not send up a modified autobuild.xml when you do an hg push.

Configuring the Viewer

If you are compiling with Fmod you will need to do:

set AUTOBUILD_CONFIG_FILE=my_autobuild.xml

At the command line in the source tree's root directory (presumably a directory you have cloned from viewer-development, as it is not a good idea to work in viewer-development, unless you are only compiling for youself) e.g. C:\linden\VWR-12345\) run:

autobuild configure -c [CONFIGURATION]

where [CONFIGURATION] is one of those listed at Building the Viewer with Autobuild#Build a desired configuration (ReleaseOS, RelWithDebInfoOS, DebugOS)

Compiling the Viewer

Compiling the viewer with autobuild

You can compile the viewer with either autobuild (the encouraged/supported method) or with the VS IDE

KBcaution.png Important: If you are building with Fmod and have followed the previous Fmod setup instructions AND you are now using a new command window you will need to redo the set AUTOBUILD_CONFIG_FILE=my_autobuild.xml.

Run:

autobuild build -c [CONFIGURATION] --no-configure

There are some useful switches to know about, so your commands may look like this:

autobuild configure -c ReleaseOS -- -DLL_TESTS:BOOL=OFF -DPACKAGE:BOOL=OFF -DFMOD:BOOL=TRUE
autobuild build -c ReleaseOS --no-configure
KBnote.png Note: It is possible to use autobuild to do both the configure step (only needed once) and the build step with one command. I find it is clearer and saves a bit of time if these steps are done separately.

Compiling the viewer with the IDE

The autobuild configure step created the \build-vc100 directory at the root of the source tree. In here is the SecondLife.sln solution file.

Start the IDE and open this solution.

You need to adjust the Platform Toolset setting.

  • Select all the projects in the Solution Explorer list on the left of the screen.
    • Click on the first project and scroll to the bottom of this list and Shift ⇧-click on the last project.
  • Right click on the selected list
  • Navigate to Properties > Configuration Properties > General > Platform Toolset
  • Change this value to Windows7.1SDK

You might want to change the build type in the drop-down from Debug to Release or RelWithDebInfo.

Push F7 to start the compiler.

Running your newly built viewer

  • Make a shortcut for Drive:\your-path\build-vc100\newview\Release\secondlife-bin.exe
  • Right-click the shortcut, Properties, and set "Start in:" to Drive:\your-path\indra\newview

Handling Problems

If you encounter errors or run into problems following the instructions above, please first check whether someone else already had the same issue. A solution might be known already. See the issue list below, check the talk page (and report useful experiences there) and search our issue tracker. Even when no description of your problem has been written down yet, someone might know about it, so get in touch with the community to get help.

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.

Common Issues/Bugs/Glitches And Solutions

Not being able to find objidl.h in the Microsoft Windows SDK, when compiling llwindow

https://lists.secondlife.com/pipermail/opensource-dev/2011-April/006562.html

  • Can be caused by path problems or some installation conflicts with the DirectX SDK.

stdint.h typedef conflicts between Quicktime and VS2010

https://lists.secondlife.com/pipermail/opensource-dev/2011-April/006565.html

  • Can be solved by some small edits to header files to make sure the two don't bash on each other.

Eliminate depreciated switches messages and use memory more efficiently

  • The VS2010 compiler uses a lot of memory while compiling the viewer. If you run out of memory you will start to page heavily and your compile time will become much longer. The /Zm1000 switch affects compiler memory usage.
  • You may see this message while compiling
use 'EHsc' instead of 'GX'

Here is how to free up some memory the compiler allocates and to eliminate these messages:

Edit \CMake 2.8\share\cmake-2.8\Modules\Platform\Windows-cl.cmake

replace line 156 with:

 IF(MSVC10)
   SET(CMAKE_CXX_FLAGS_INIT "/DWIN32 /D_WINDOWS /W3 /EHsc /GR")
 ELSEIF(NOT MSVC10)
   SET(CMAKE_CXX_FLAGS_INIT "/DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR")
 ENDIF(MSVC10)

replace line 172 with:

 IF(MSVC10)
   SET(CMAKE_CXX_FLAGS_INIT "/DWIN32 /D_WINDOWS /W3 /EHsc /GR")
 ELSEIF(NOT MSVC10)
   SET(CMAKE_CXX_FLAGS_INIT "/DWIN32 /D_WINDOWS /W3 /Zm1000 /GX /GR")
 ENDIF(MSVC10)

replace line 184 with :

 IF(MSVC10)
   SET(CMAKE_CXX_FLAGS_INIT "/DWIN32 /D_WINDOWS /W3 /EHsc /GR")
 ELSEIF(NOT MSVC10)
   SET(CMAKE_CXX_FLAGS_INIT "/DWIN32 /D_WINDOWS /W3 /Zm1000 /GX /GR")
 ENDIF(MSVC10)

References