CONFIG_* defines

[Bernhard Fischer]

On Tue, Sep 06, 2005 at 09:01:03PM +0400, Vladimir N. Oleynik wrote:
>Bernhard,
>
>>regarding that 3). Can you please explain that a little bit?
>>
>>
>>We could just move the CONFIG_* namespace to something different,
>>for example BUSYBOX_APPLET_* and BUSYBOX_APPLET_*_{FOO,BAZ,...}
>>I know that the cons -- several patches in the bugtracker may not apply
>>cleanly any more etc. -- were already brought up..
>>
>>Just as an example, i'm attaching an applet runlevel(8). The only thing
>>which would need to be touched would be bbconfig for it to allow
>>BUSYBOX_* along the by then old/legacy CONFIG_* entries in .config.
>
>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.

>I think, best is
>CONFIG_APPLETNAME, APPLET_FEATURE_NAME, BB_FEATURE_NAME.

I beg to differ.
CONFIG_APPLETNAME is inherently 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'd be willing to help going through busybox to make that change in a
coordinated way, if that helps.

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. That said, libbusybox.so which includes all the
helper-libs mentione in an other thread before still would _currently_
pollute the global symbol space via it's far too generic bb_*()
functions (it wouldn't in practice, but it's error prone) but it would
at least help the linker to be able to choose the correct lib to use.

cheers,
Bernhard