Palm OS Programming, 2nd Edition

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 ErrFatalDisplay and ErrNonFatalDisplay macros are expanded to calls to display fatal errors. On a release build, the ErrNonFatalDisplay macros do nothing, although the ErrFatalDisplay macros still display fatal errors.

DEBUG_BUILD symbol 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 ...