CONFIG_FEATURE_ versus ENABLE_FEATURE_

[Bernhard Fischer]

On Thu, Apr 06, 2006 at 09:58:33AM -0400, Robert P. J. Day wrote:
>On Thu, 6 Apr 2006, Bernhard Fischer wrote:
>
>> On Thu, Apr 06, 2006 at 09:30:50AM -0400, Robert P. J. Day wrote:
>> >
>> >  is there a recipe for the proper usage of macros CONFIG_FEATURE_x
>> >versus ENABLE_FEATURE_x?  superficially, it's obvious that the
>> >"CONFIG" macros are to be used in preprocessor directives, while the
>> >"ENABLE" ones are to be used in actual C code, but that's not always
>> >followed.
>>
>> In the long run, we will switch everything to ENABLE_.
>> Either
>> 	if (ENABLE_whatever)
>> 		foo;
>> or, if need be
>> #if ENABLE_whatever
>> # include this
>> static unsigned that;
>> #endif
>
>ok.  and i assume that (non-boolean) config options that take actual
>values will remain as they are?  things like
>
>	CROSS_COMPILER_PREFIX
>	EXTRA_CFLAGS_OPTIONS
>
>and so on?

It was proposed that the whole CONFIG_ namespace of Config.in should be
moved to BB_ to avoid clashes with the (non-cleaned up) kernel-headers.

The two options you list above should never end in C-space at all. At
least i don't see what that would gain.

gcc may at one point in the future support adding the flags used for
building into the objects, so we'd (optionally) have them in the
busybox_unstripped, but first, we'll of course strip these for the final
busybox binary and second, i don't see a real benefit to emit any flags
into the objects in the first place.