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