[BusyBox] CONFIG_ name clashing with kernel

[Mike Frysinger]

On Tuesday 02 August 2005 02:03 am, Rob Landley wrote:
> On Monday 01 August 2005 21:16, Mike Frysinger wrote:
> > On Monday 01 August 2005 05:42 pm, Rob Landley wrote:
> > > On Sunday 31 July 2005 17:59, Mike Frysinger wrote:
> > > > all the CONFIG_ defines we're using in busybox have lead to name
> > > > space clashing with the kernel ...
> > > >
> > > > http://bugs.busybox.net/view.php?id=316
> > > >
> > > > we can rename these three defines (SYSCTL/TR/WATCHDOG) or we could
> > > > take care of this now (and forever) by replacing all of the macros
> > > > with a different namespace:
> > > > BB_CONFIG_*
> > >
> > > Let's not make the prefix longer, thanks.
> > >
> > > I just put in the ENABLE_ replacement for CONFIG_, and left the old one
> > > so we wouldn't have change all the existing #ifdefs.  However, if the
> > > existing #ifdefs are horked...
> >
> > that still doesnt 'namespace' it to busybox ... that means we have to be
> > careful not to use the same feature names in busybox, uClibc, the kernel,
> > and anything else that happens by
>
> Busybox is, fundamentally, just a userspace app.  Nobody should be
> inheriting our headers.
>
> The problem is that the C library (uClibc) is inheriting symbols from the
> kernel headers.  Those heades _are_ meant to be inherited, and those two
> should be namespaced so as not to pollute the application namespace.

i'm not talking about other projects using busybox headers, i'm referring to 
the kernels/libraries busybox is being built against ... the namespace is 
being polluted underneath busybox and there really isnt anything we can do 
about that except minimize the chances of collision by using a somewhat 
unique namespace such as 'BB_CONFIG_'

going with a generic name like 'ENABLE_' just sets us up for 'next time'
-mike