[U-Boot-Users] [PATCH] fix compilation problem for mpc8349itx CFG_RAMBOOT

[Timur Tabi <timur@freescale.com>]

Wolfgang Denk wrote:
> In message <46548B5B.4060607@freescale.com> you wrote:
>>> This is extremely inconsistent. Some CONFIG_COMMANDS_* (PCI, I2C) are
>>> used to add features, while others (FLASH) are used to remove
>>> features. I consinder this very error prone.
>> Well, it's supposed to be an alternative to what Nikita was proposing.  I wanted to keep 
> 
> It's bad. Use something like __CMD_ADD_I2C or  __CMD_REMOVE_FLASH  or
> so, but don't use the same name for different functions.

Ok, I can change those names.

> 
>> Please take a look at my MPC8349ITX.h to see the full extent of what I was trying to do. 
> 
> Yes, I know what it does. Frankly, it's ugly.

As Nikita pointed out, the ugliness is just a side-effect of the way CONFIG_COMMANDS is 
defined and a limitation of C macros.  A macro can only be defined once, and you can't put 
#ifdefs inside the #define, so you have two choices:

1) Use #ifdefs around #define CONFIG_COMMANDS to have the compiler choose *which* version 
of CONFIG_COMMANDS you want to actually compile

2) Create sub-macros (e.g. with __CMD_xxx) that are defined inside #ifdefs, and then make 
CONFIG_COMMANDS a combination of those macros.

I believe that option #1 scales better than option #2, and therefore is easier to read.

>> Should they be renamed to CFG_COMMANDS_xxx?
> 
> No, as  CFG  also  has  a  specific  meaning.  Here,  you  just  need
> temporary,  local  variables.  Please avoid name space pollution. You
> can and should even #undef those after use.

As NIkita demonstrated, you can't undefine those macros.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale