72 2. Tools of the Trade
Linker Settings
The linker also exposes a number of options. You can control what type of
output fi le to produce—an executable or a DLL. You can also specify which
external libraries should be linked into your executable, and which directory
paths to search in order to fi nd them. A common practice is to link with de-
bug libraries when building a debug executable and with optimized libraries
when building in release mode.
Linker options also control things like stack size, the preferred base ad-
dress of your program in memory, what type of machine the code will run on
(for machine-specifi c optimizations), and a host of other minutia with which
we will not concern ourselves here.2.2.4.2. Typical Build Confi gurations
Game projects oft en have more than just two build confi gurations. Here are a
few of the common confi gurations I’ve seen used in game development.
z Debug. A debug build is a very slow version of your program, with all
optimizations turned off , all function inlining disabled, and full debug-
ging information included. This build is used when testing brand new
code and also to debug all but the most trivial problems that arise dur-
ing development.
z Release. A release build is a faster version of your program, but with
debugging information and assertions still turned on. (See Section
3.3.3.3 for a discussion of assertions.) This allows you to see your game
running at a speed representative of the fi nal product, but still gives you
some opportunity to debug problems.
z Production. A production confi guration is intended for building the fi nal
game that you will ship to your customers. It is sometimes called a “Fi-
nal” build or “Disk” build. Unlike a release build, all debugging informa-
tion is stripped out of a production build, all assertions are usually turned
off , and optimizations are cranked all the way up. A production build is
very tricky to debug, but it is the fastest and leanest of all build types.
z Tools. Some game studios utilize code libraries that are shared between
offl ine tools and the game itself. In this scenario, it oft en makes sense
to defi ne a “Tools” build, which can be used to conditionally compile
shared code for use by the tools. The tools build usually defi nes a pre-
processor macro (e.g., TOOLS_BUILD) that informs the code that it is be-
ing built for use in a tool. For example, one of your tools might require
certain C++ classes to expose editing functions that are not needed by
the game. These functions could be wrapped in an #ifdef TOOLS_