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 _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
