svn 23941 (comments on config symbol renaming).

[Rob Landley]

Way way back in the dark ages, the original reason for naming symbols 
CONFIG_APPLETNAME and CONFIG_FEATURE_APPLETNAME_BLAH was so that so that 
things like "make allbareconfig" could could easily filter out features via a 
sed invocation looking for "CONFIG_FEATURE".

This was a build test, because a few times we found build breaks when a 
feature was _disabled_, because we tested allyesconfig and allnoconfig but 
couldn't easily test enabling each applet but switching each sub-feature 
_off_.  So I added "make allbareconfig" to make sure each applet feature 
would at least compile with all its features disabled.  That build option 
seems to have gone away since 1.2, any idea why?

Ignoring that constraint, it does make more sense for config features to be 
named CONFIG_APPLETNAME_SUBFEATURE, and that's what I did with toybox.  (I 
also named global features "CONFIG_TOYBOX_SUBFEATURE"; again, easy to 
spot 'em with config editing tools if you're consistent in the naming.)

Busybox had CONFIG_DEBUG_ as a prefix when defconfig was made via sed, because 
all those needed to be filtered out.  These days, you can just as easily grep 
for "_DEBUG" if you want to filter out debug features that way, and the 
kconfig infrastructure's been updated to accept a driedfrogpills file to 
switch the debug features off that way.  (It's sort of the opposite of a 
miniconfig file, supplementing allyesconfig with symbols to be switched 
_off_.)

I don't really know what the plans are for the config infrastructure.  (It 
seems lots of the customizations we had got yanked out when it was resynced 
with the upstream kernel infrastructure?)  Are things like allbareconfig 
still interesting?

Rob