Difference between revisions of "Building SourceMod"

From AlliedModders Wiki
Jump to: navigation, search
(New page: 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 dir...)
(No difference)

Revision as of 22:16, 17 January 2008

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.

Requirements

Windows

  • Microsoft Visual C++ 2005 (Express or higher) is supported and used for official builds.
  • Microsoft Visual C++ 2008 (Express or higher) is unsupported, but can load and build SourceMod's 2005 project files.
  • 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. That means if you try to build it on a 64-bit compiler, it will fail to build or load. On Windows this should not be a problem, but a 64-bit Linux machine may build 64-bit binaries by default. If this is the case, you may need to edit the CFLAGS line of the Makefile(s) to have -m32 (which tells GCC to build 32-bit libraries).

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 Subversion. We have our own Subversion 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.

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

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
    • sourcemm-1.4.2 - symlink or folder containing any Metamod:Source version 1.4.2 or higher.
    • sourcemm - symlink or folder containing any Metamod:Source version 1.6 or higher.
    • trunk - folder containing SourceMod's source code tree. This can be named anything; we have called it trunk to represent that it came from /svnroot/sourcemod/trunk.
    • mysql-5.0 - symlink or folder containing a MySQL 5.0 distribution

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.

  • SOURCEMM - Path to Metamod:Source 1.6+
  • SOURCEMM142 - Path to Metamod:Source 1.4.2+
  • HL2SDK - Path to HL2SDK Ep1/Original
  • HL2SDKOB - Path to HL2SDK Ep2/OrangeBox


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.2+/HL2SDK
  • Episode1 - Building against MM:S 1.6+/HL2SDK (Unsupported)
  • Episode2 - Building against MM:S 1.6+/HL2SDK-OB

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

Dependent Binaries

Binaries that have an Engine or MM:S dependency will have one or more of the following Makefiles. Note that these refer to the build types mentioned earlier.

  • Makefile.orig - Original build.
  • Makefile.ep1 - Episode1 build (unsupported).
  • Makefile.ep2 - Episode2 build.

The only difference with using these Makefiles is that you must specify -f <file>. For example, to build a TF-compatible binary in debug mode: 

make -f Makefile.ep2 debug

Note: The Release and Debug outputs folders are used for each Makefile, and thus it is imperative you clean the object cache before proceeding to build another.

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 1 (unsupported)
  • Debug - Episode 2
  • Release - Old Metamod
  • Release - Episode 1 (unsupported)
  • 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. The closed-source binary, sourcepawn.jit.x86, is not compiled with SSE, and thus you do not have to worry about it.

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.


Future Changes

It is likely in the future that the environment vars will change:

  • SOURCEMM142 -> SOURCEMM14
  • SOURCEMM -> SOURCEMM16

The Linux Makefiles may change to use different output folders for dependent binaries. Similarly, the separate file idea may be scrapped to combine different builds into one file.

If such changes are made, this document will be updated.

Retrieved from "https://wiki.alliedmods.net/index.php?title=Building_SourceMod&oldid=5524"