Nice kconfig hack

[Rich Felker]

On Wed, May 02, 2012 at 10:44:51AM -0500, Rob Landley wrote:
> >>> #define is_set(macro) is_set_(macro)
> >>> #define macrotest_1 ,
> >>> #define is_set_(value) is_set__(macrotest_##value)
> >>> #define is_set__(comma) is_set___(comma 1, 0)
> >>> #define is_set___(_, v, ...) v
> >>
> >> It's clever, but there's a problem:
> >>
> >> Right now, if you leave in a test for a symbol that's been removed, or
> >> if you typo a symbol name, the build will break. And this is good, it
> >> shows you what needs fixing.
> >>
> >> With this new mechanism, testing for a symbol that _can't_ ever be set
> >> means there's dead code in the source which the compiler won't warn you
> >> about.
> >>
> >> *shrug*  Maybe it's still worth doing, not my call...
> > 
> > I would just institute a policy of "grep -r" whenever a test symbol is
> > removed... That's a lot cheaper than maintaining busybox's current
> > config monstrosity.
> 
> And this will catch typos?

That's a completely separate issue than your original objection, and I
would think typos (in new conditional code) would be caught when the
person first adding the code tries it out to see if it works...

> Announcing a policy that humans should do something manually as part of
> their development process seems useful to you?

I tend to think O(1) manual work is preferable to O(n) machine work
especially when there are human being waiting for the machines to
finish their work (i.e. one person does something right when they
commit the code, versus every user/developer sitting around waiting
for slow scripts every time they type make.)

> *shrug*  As I said, not my call. I always said the correct fix was to
> get kconfig to output the symbols we actually _need_, and now Linus is
> going "hey, these are the symbols we actually need" and doing an overlay
> to get them instead of fixing the infrastructure to output the right stuff.

I dislike the whole kconfig mess (which makes each invocation of
"make" just to recompile one changed file and relink take forever)
at least as much as I dislike GNU autotools, but since nobody seems
willing to overhaul or abandon it, I figure at least this would be a
step in the right direction... (i.e. away from the slow and ugly
scripts to manage getting config into the format it's needed in).

Rich