[U-Boot-Users] [PATCH] fix compilation problem for mpc8349itx CFG_RAMBOOT
Timur Tabi
timur at freescale.com
Wed May 23 22:29:18 CEST 2007
Wolfgang Denk wrote:
> In message <46548B5B.4060607 at 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
More information about the U-Boot
mailing list