CONFIG_* defines

[Bernhard Fischer]

On Tue, Sep 06, 2005 at 07:18:58PM -0500, Rob Landley wrote:
>On Tuesday 06 September 2005 11:36, Bernhard Fischer wrote:
>
>> >3)
>> >include/config/feature/ ... bla-bla is unstandardization
>>
>> regarding that 3). Can you please explain that a little bit?
>>
>>
>> We could just move the CONFIG_* namespace to something different,
>> for example BUSYBOX_APPLET_* and BUSYBOX_APPLET_*_{FOO,BAZ,...}
>> I know that the cons -- several patches in the bugtracker may not apply
>> cleanly any more etc. -- were already brought up..
>>
>> Just as an example, i'm attaching an applet runlevel(8). The only thing
>> which would need to be touched would be bbconfig for it to allow
>> BUSYBOX_* along the by then old/legacy CONFIG_* entries in .config.
>
>I'm not quite sure what vodz means by #3, but in terms of moving the CONFIG_ 
>namespace:
>
>I've been slowly switching things over to the ENABLE_* macros, which instead 
>of being defined or undefined are always defined, but to 0 or 1.  That way 
>they can be used in normal if() statements.  Since it's a constant, the 

Yes, since you started to do that, i'm getting:
applets/applets.c:447: warning: empty body in an if-statement
applets/applets.c:455: warning: empty body in an if-statement
applets/busybox.c:74: warning: empty body in an if-statement
See e.g. allnoconfig.

>compiler's "dead code elimination" optimization (a very old and very simple 
>optimization, one even fabrice bellard's "tiny C compiler" does) can chop 
>them out.

yes, tcc also has dead code elimination. It doesn't support
variable-sized arrays, currently. It should be taught to deal with them
as they are useful generally and also used in busybox. I remember i got
some headache from starting to support tcc -E some time ago, though.
>
>This is much easier to read and maintain than nested #ifdefs in the middle of 
>C functions...

Yes, i agree. What _i_ would like to do is to sed -e "s/CONFIG_/BUSYBOX_/g".