VARIANT=DEBUG was Re: Conditional debug code

[Ralf Corsepius]

On Wed, 2003-12-10 at 19:59, Joel Sherrill wrote:
> Charles Steaderman wrote:
> 
> > Does the base RTEMS build procedure set a compilation define when I do a 
> > build with VARIANT=DEBUG?
No.

>  I would like to conditionally compile code 
> > with #ifdef DEBUG ... #endif (or something like that). I know that I can 
> > update mybsp.cfg but if the base build procedure sets a define already I 
> > would like to use the built-in define.
There is no such define - intentionally, because such defines are
error-prone, unsafe and dangerous.

Why am I saying so?

1. A legitimate usage of such a define would be to switch on debugging
code inside of implementation files (*.c/*.cc-files) or private headers
(*.h files that don't get exported from the source tree).

However, it is tempting to also use such a define within public headers.
I.e. if not being cautious, the API specified by such a header could
become compilation context/compiler-flag sensitive.

Worse, as such flags can be specified and overridden at various places,
you could end up with using different/inconsistent APIs or settings in
different files.

2. preprocessor flags can alter file dependencies. 
A "simple"
#if DEBUG
#include <stdio.h>
#endif
or 
#if DEBUG
#include <math.h>
#endif
completely changes a program's behavior and dependencies.

This would break your Makefiles.

3. Compilation flags influence configuration checks.
(A flag set at make time can result into completely different compiler
behavior, if not being set at configuration time) [1]

So if you really know what you are doing, you could (temporarily, for
debugging/development/testing purposes) 
* add such a define to your <bsp>.cfg,
* use CFLAGS_FOR_TARGET
* manually set it by using make CFLAGS="<value>" or 
make CPPFLAGS="<value>" for individual subdirs.

I'd recommend using CFLAGS_FOR_TARGET.

> Ralf has been working to get rid of the concept of build variants and
> follow the GNU conventions.  I will have to leave it to him to tell
> us all the GNUitically correct way to do it now. :)
Well, this actually has nothing to do with GNU conventions nor with
auto*tools. 

Basically, it's all about
* code safety (avoiding errors)
* compilation consistency (Using the same set of defines throughout all
components).
* simplicity (reduction of complexity)
* SW-design.

All the auto*tools do wrt. this is to partially enforce this.

Ralf

[1] Current RTEMS configuration and build scheme ignores this.
Therefore, IMNSHO, variant building is broken and should be replaced or
removed, ASAP.