Release/Debug Targets
It’s common to create two different builds: one for debugging and one for actual production (release) code. The differences between the two are as follows:
- Optimization level
For ease of debugging, you usually turn off optimization. If you don’t, funny things can occur. For example, if you have two stack variables that are actually located at the same position in memory, then changing one makes the other appear to change in the debugger. For your release version, however, you want to turn on optimization.
- Embedded routine names
Embedded routine names are important for debugging so that you can do profiling. They unnecessarily bulk up to your shipping application—so pitch them. As an example, one C++ application we wrote went from 110K to 99K just by turning off embedded routine names.
- Fatal error display
On a debug build, both
ErrFatalDisplayandErrNonFatalDisplaymacros are expanded to calls to display fatal errors. On a release build, theErrNonFatalDisplaymacros do nothing, although theErrFatalDisplaymacros still display fatal errors.-
DEBUG_BUILDsymbol is set You can conditionally compile in debug code by enclosing it in:
#ifdef DEBUG_BUILD ... #endif
Of course, don’t do all your testing with the debug version, and then build a release version and ship that without testing. You need to test with the release version, especially since optimizations can often cause problems.
Releasing and debugging builds in CodeWarrior
Latent bugs in your source ...