CONFIG_FEATURE_ versus ENABLE_FEATURE_

Robert P. J. Day rpjday at mindspring.com
Thu Apr 6 15:54:03 UTC 2006


On Thu, 6 Apr 2006, Bernhard Fischer wrote:

> 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.

ok ... so the end result will be what, exactly?  no more CONFIG_
macros, just ENABLE_ macros?  and what will happen to this BB_ prefix?
i'm just trying to sort this out in my mind.

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

that makes sense, sure.  thanks.

rday



More information about the busybox mailing list