Building SourceMod

Compiling SourceMod is not difficult, but requires a number of prerequisites. This article details the requirements and steps to being able to build working SourceMod binaries. These directions may change any time and may be updated as SourceMod's build process improves.

Note: You cannot use MingW to build working SourceMod Windows binaries. It is not ABI compatible with Visual C++ which is what Valve uses for the Source engine. You can only use GCC to build Linux binaries.

Requirements

Windows

• Microsoft Visual C++ 2008 (Express or higher) is supported and used for official builds.
• Microsoft Visual C++ 2005 (Express or higher) is unsupported.
• Microsoft Visual C++ 2003 7.1 or higher may not build out-of-box, but can build compatible binaries.
• Microsoft Visual C++ 2003 7.0 or lower cannot be used.

If you are installing Visual C++ 2005 Express, it may not come with Microsoft's Platform SDK installed. If this is the case, you must manually install the Platform SDK. You can find directions on how to do this and test your setup here. Visual C++ 2008 "streamlines" the Platform SDK installation according to Microsoft.

Linux

For Linux, SourceMod requires the GNU C/C++ Compiler (from GCC):

• Version 4.1 is used for official binaries and is guaranteed to build.
• Versions 3.4 through 4.2 are guaranteed to be binary (ABI) compatible, although SourceMod may not necessarily build out-of-box against them.
• Any GCC version below 3.4 cannot be used.

CPU

SourceMod is strictly a 32-bit x86 (IA32) product. You should not try to force a compiler to build 64-bit binaries of SourceMod.

Your CPU and its compiler must support SSE in order to build SourceMod. To build without needing or having a dependency against SSE, please see the Removing SSE section near the bottom.

Approximate compiling times for SourceMod's Core are roughly:

• Windows, Core 2 Quad E6600: 30 seconds (using /MP)
• Windows, Core 2 Duo E6600: 75 seconds
• Windows, Centrino 1.8GHz: 5 minutes
• Linux, Core 2 Duo E6600: <= 1 minute
• Linux, P3 Dual 500MHz: >= 7 minutes

Setup

This section describes how to set up your computer for compiling.

Getting the Files

This section describes which files you must obtain and how to obtain them. Do not worry about where to place them yet -- that will be discussed on a per-platform basis. You can download the files anywhere you'd like.

The recommended method of getting the required files is via Mercurial. We have our own Mercurial_Tutorial if you prefer that method. Although you do not need both HL2SDK versions (unless you wish to build binaries against both), you do need both Metamod:Source versions. Extensions don't necessarily require Metamod:Source (or even the Source Engine) but its template library is used extensively in SourceMod.

• SourceMod. For full download options, see the SourceMod Downloads page. Obviously, you must download the source code and not a binary package.
• HL2SDK Original. As of this writing (Sep 2008) this engine is used for most Source games, except for TF2, GMod10, and DoD:S. Repository: hl2sdk
• HL2SDK OrangeBox. As of this writing (Sep 2008) this engine is used TF2, GMod10, and DoD:S. Repository: hl2sdk-ob
• HL2SDK Left4Dead. This engine is used for L4D. Repository: hl2sdk-l4d
• Metamod:Source Source Code. Visit Metamod:Source downloads. Right now SourceMod builds against Metamod:Source 1.7.

Note that when we refer to "Metamod:Source" in this article, we are referring to its source code tree, not a binary package.

If you intend to compile the MySQL extension, you must also download MySQL 5.0. You can use any version. For simplicity, here are the versions we use:

• Linux: We use the 5.0.45 binary from the "Linux (non RPM packages)" for "Linux (x86)." You can also use this direct link (may not be valid in the future).
• Windows: Due to a MySQL build change we use 5.0.24a which is an older download. The file name was "mysql-5.0.24a-win32.zip," if you can't find it you can use this direct link (may not be valid in the future).

You can remove all folders from the distribution except for the "lib" and "include" folders which comprise the MySQL SDK.

Linux

As of this writing, SourceMod's Makefiles are hardcoded to use a binary called "gcc-4.1" You can override this, for example:

make CPP=gcc

Otherwise, you can also just create a symlink:

sudo ln -s /usr/bin/gcc /usr/bin/gcc-4.1

Note that you must use gcc and not g++.

SourceMod's Makefiles have strict directory organizational rules. You must have a top-level folder. For this document, we'll assume it is called sourcemod, though it can be named anything. The layout of sourcemod must be:

• sourcemod/
  • hl2sdk - symlink or folder containing the HL2SDK
  • hl2sdk-ob - symlink or folder containing the HL2SDK for Orange Box/TF
  • mmsource-1.7 - symlink or folder containing any Metamod:Source version 1.7 or higher.
  • sourcemod-central - folder containing SourceMod's source code tree. This can be named anything, as long as it's a valid SourceMod tree (like sourcemod-central). You can also use sourcemod-1.1.
  • mysql-5.0 - symlink or folder containing a MySQL 5.0 distribution

If you are using a 64-bit version of Linux, you may need to install extra packages to be able to compile SourceMod. On Debian-based distros, these are typically:

#prerequisites
#apt-get install g++-4.1 gcc-4.1 make subversion
#apt-get install libz libz-dev
#only needed if you want to use the build tool
#apt-get install mono mono-devel
#32-bit support
apt-get install ia32-libs
apt-get install lib32z1 lib32z1-dev
apt-get install libc6-dev-i386 libc6-i386

Windows

On Windows we don't require a particular directory layout. Instead, environment variables are used. The directions below apply to Windows XP, and are assumed to be similar for other versions of Windows.

• Open the Control Panel (for example, via Start -> Settings).
• Open the System control. If you don't see it, you may need to switch to "Classic view" (either via the left-hand pane or by going to Tools -> Folder Options).
• Click the Advanced tab.
• Click the Environment Variables button.

You can add your environment variables to either your User settings or your System settings. Create a new variable for each item in the list below. The item names are in fixed-width font and their value descriptions follow.

• MMSOURCE17 - Path to Metamod:Source 1.7+
• MMSOURCE18 - Path to Metamod:Source 1.8+
• HL2SDK - Path to HL2SDK Ep1/Original
• HL2SDKOB - Path to HL2SDK Ep2/OrangeBox for mods
• HL2SDKOBVALVE - Path to HL2SDK Ep2/OrangeBox for Valve games (TF2 and DoD:S)
• HL2SDKL4D - Path to HL2SDK L4D1
• HL2SDKL4D2 - Path to HL2SDK L4D2

Building

SourceMod has two types of binaries: those with an engine/MM:S dependence, and those without ("normal" binaries). Normal binaries have two modes:

• Release - Optimized binary for release.
• Debug - Unoptimized binary with debugging checks.

Engine/MM:S dependent binaries have three build modes, each paired with either Release or Debug, meaning there are six build options total. They are:

• Original - Building against MM:S 1.4 API with HL2SDK
• Episode2 - Building against MM:S 1.6 API with HL2SDK-OB or higher

Linux

For both Normal and Engine/MM:S dependent binaries, the object files and the final binary are placed in a folder called Release or Debug (in the same level as the Makefile) depending on which building mechanism you chose.

Note: Our Makefiles are not set up to detect changes in header files. If you change a header file, you must clean your build.

Normal Binaries

For normal binaries, you can build simply with:

make

You can clean stale object files with:

make clean

Or build debug builds with:

make DEBUG=true

Dependent Binaries

Binaries that have an Engine or MM:S dependency require one extra parameter, ENGINE. It must be either orangebox or original. For example, to build a TF-compatible binary in debug mode:

make ENGINE=orangebox DEBUG=true

Dependent binaries are dropped into one of the following folders:

• Debug.original
• Debug.orangebox
• Release.original
• Release.orangebox

Windows

Windows project files end with .vcproj and are found in an msvc8 folder that resides inside each binary's main source folder. For example, Core is located in core/msvc8/sourcemod_mm.vcproj.

Once the file is opened, you can select which build to use by going to Build -> Configuration Manager. Normal binaries have simply "Debug" and "Release." Dependent binaries have the following builds:

• Debug - Old Metamod
• Debug - Episode 2
• Release - Old Metamod
• Release - Episode 2

Note that dependent binaries will have plain "Debug" and "Release" builds. These should not be used as they are not configured.

Once you have selected a configuration, you can compile by going to Build -> Build Solution. The binaries and object files will be written to a folder inside msvc8 named after the full configuration name. For example, using "Debug - Old Metamod" with the "sdktools" extension will result in the binary: extensions/sdktools/msvc8/Debug - Old Metamod/sdktools.ext.dll

Note: Visual Studio detects changes to header files intelligently. It is usually not necessary to rebuild a solution.

Binary Organization

Although SourceMod has a somewhat unified building mechanism, each of the binaries has a different purpose. They can be separated into the following classes:

• Core-Related: Binaries which are required or loaded intrinsically by Core.
• Extensions: Binaries which are loaded via the extension mechanism.
• External: Binaries which are standalone or unrelated to SourceMod's live operation (for example, the compiler).

This article is only concerned with the first two types.

Core-Related Binaries

Binaries related to Core are spread throughout the source code tree. They are always placed in sourcemod/bin for packaging. The projects files related to Core are:

• loader - This is a very small wrapper binary responsible for detecting the MM:S version and game engine, and deciding which SourceMod version to load. The output binary is sourcemod_mm_i486.so or sourcemod_mm.dll.
• core - This is Core itself, and is a dependent binary. It has three outputs:
  • Original: sourcemod.1.ep1.so/sourcemod.1.ep1.dll
  • Episode 1: sourcemod.1.ep1.so/sourcemod.2.ep1.dll (unsupported, not packaged)
  • Episode 2: sourcemod.1.ep1.so/sourcemod.2.ep2.dll
• sourcepawn/jit/x86 - This is the SourcePawn JIT for generating IA32/x86 instructions from .smx files. Currently the source code for this is not made available. It is built as sourcepawn.jit.x86.so/sourcepawn.jit.x86.dll.

It is technically not necessary to use the loader. It is provided as a convenience so users do not have to perform extra steps while installing SourceMod. However, it is highly recommend that you do use it in order to maintain similarity with the default SourceMod package.

Extensions

Extensions are found in the extensions folder of the source tree. SDKTools, Cstrike, and the upcoming TF extension are engine/MM:S dependent (and the rest are generally not).

Extensions always are named name.ext.so or name.ext.dll where name is a unique identifier. This is true even of dependent binaries.

When loading extensions, SourceMod looks in two separate folders. First, it checks the dependent extension folder, which is extensions/auto.x.y where x is the MM:S version (1 for 1.4, 2 for 1.6) and y is the Engine version (1 for Original/Ep1, 2 for Ep2/OrangeBox). If no matching extension is found there, it looks in extensions.

For example, the SDKTools binary on Counter-Strike would be loaded from extensions/auto.1.ep1, but the GeoIP binary (which is not dependent) would be loaded from extensions.

Removing SSE

SourceMod binaries are built against SSE by default. SSE is an important set of optimizations, that, according to Valve's hardware survey, are supported on 99.6% percent of respondents' computers. If you are in this 0.4% which does not have SSE support, you should consider buying a newer processor. Only early Pentium 3-grade processors did not have SSE support (for example, the very early Durons), and it is likely your Source server will not perform adequately to support more than few players.

Nonetheless, SourceMod's binaries can all be recompiled to remove its SSE dependence.

Linux

Edit the Makefile of the binary you are trying to compile. Remove all instances of these flags. They can simply be erased, there is no need to replace them with anything.

• -msse
• -mfpmath=sse

Make sure to clean the build after changing the Makefile.

Windows

Load the project file into Visual Studio. Go to Project -> Properties. Expand "Configuration Properties," and then "C/C++" under it. Select "Code Generation." Change the setting "Enable Enhanced Instruction Set" to "Not Set."

Note: You must change this setting for each build configuration that you wish to use.