CONFIG_* defines

[Bernhard Fischer]

On Tue, Sep 06, 2005 at 11:33:05PM -0500, Rob Landley wrote:
>On Tuesday 06 September 2005 14:10, Bernhard Fischer wrote:
>> >Why BUSYBOX_APPLET_NAME?
>>
>> Because it minimizes the risk to clash with the default (kernel's et al)
>> CONFIG_ hierarchy now and at any point int the future.
>
>A risk that only exists because we grabbed the kernel's config system in the 
>first place, I might add.

right.
>
>In theory, these symbols should not be exposed to userspace.  Maszur's cleaned 
>up kernel headers certainly don't include this.  (Of the many broken things 
>about glibc's headers, this probably doesn't even register, of course.  Ever 
>looked at the fix_includes script?  Makes your brain hurt...)

>> >I think, best is
>> >CONFIG_APPLETNAME, APPLET_FEATURE_NAME, BB_FEATURE_NAME.
>>
>> I beg to differ.
>> CONFIG_APPLETNAME is inherently broken.
>
>I disagree.  Using maszur's headers there's no clash.  Glibc's headers that 
>pollute the standard namespace with kernel implementation details are what's 
>broken.

Yes, i agree 100% that this is broken.
>
>> Iff we can agree (not that i'm 
>> in the position to say anything ;) on BUSYBOX_APPLETNAME and
>> BB_FEATURE_NAME, then ok. Everything else it is error prone, in
>> practice.
>
>I mentioned switching stuff over to 0/1 based symbols (rather than 
>undefined/devined) with the prefix ENABLE_ instead of CONFIG_.  The reason 

I'm talking about the CONFIG_* in the Config.in's and not the ENABLE_*
from bb_config.h

in Config.in, i'd suggest to use
config BUSYBOX_TAR
config BUSYBOX_TAR_CREATE
etc.
which would end up in bb_config.h as ENABLE_TAR and
ENABLE_FEATURE_TAR_CREATE like it does now.


>for this was to avoid a big flag day patch changing all the existing config 
>symbols all at once, but if you want I can indeed change them all at once.

Personally, i'd prefer them to be changed soonish, but i'm an innocent
bystander :)
>
>Every existing #ifdef CONFIG_* would become #if ENABLE_*, and #ifndef would 
>become #if !ENABLE_*...

Yes, i got that and do like it.
>
>> PS: there are also other bb*() namespaces, to name just one, libbb from
>> blackbox-tools. I'm not arguing that libbb there is better named than
>> the local libbb, but i still think that it should be possible to avoid
>> potential namespace clashes and perusing a meaningful namespace for a
>> given project.
>
>If you check in a patch with that level of paranoia, I'm likely to submit a 

I don't check in anything, i rely on kind folks with write-access to do
that.
[snip superfluous discussion that followed here]

friendly,
Bernhard