CONFIG_* defines

[Rob Landley]

On Monday 12 September 2005 02:56, Vladimir N. Oleynik wrote:

> depend work now!

Cool.

> But:
> Why libunarchive/unarchive.c depended with config.h?

I have no idea.  It almost certainly shouldn't be.  (Since busybox.h and 
libbb.h already #include config.h and bb_config.h, other stuff really 
shouldn't do so directly.)

> What is it include/bb_config.h, why include/config.h splitted?

The purpose of "config.h" is to "#define CONFIG_SYMBOLS", which are then 
tested with #ifdef or #ifndef.  (I.E. only enabled symbols are #defined.)  

The purpose of "bb_config.h" is to #define an ENABLE_SYMBOL version of each 
CONFIG_SYMBOL, which conveys the same information but instead of being 
#defined or #undefined is always defined as either 1 or 0.  Since the ENABLE 
symbols are always defined, you can use them as constants in normal if() 
statements in normal C code (which the compiler will then optimize out for 
the if(0) case).  You can also use them in preprocessor tests, just use "#if 
ENABLE_SYMBOL" instead of "#ifdef ENABLE_SYMBOL".

For example, code based on CONFIG symbols has to use the preprocessor and 
tends to lead to code like:

#ifdef CONFIG_THINGY
 if (!(x=malloc(42))) {
  do_stuff();
 } else {
#endif
  do_other_stuff();
  do_more_stuff();
#ifdef CONFIG_THINGY
 }
#endif

Whereas the ENABLE version looks like:

 if(ENABLE_THINGY && !(x=malloc(42))) {
  do_stuff();
 } else {
  do_other_stuff();
  do_more_stuff();
 }

Which should compile to exactly the same thing if ENABLE_THINGY is a constant 
0.  (Dead code elimination is one of the easiest optimizations there is.  
Note that even the old dos compiler Turbo Pascal could do dead code 
elimination, as can modern "tiny" compilers like TCC and SDCC.)

With the enable version, you're also less likely to have build breaks or 
warnings that only happen in certain config settings.

Rob