On Sat, May 24, 2008 at 09:14:46PM +0100, Jeremy Fitzhardinge wrote: > Andrew Morton wrote: > >It could help to get us out of the occasional sticky situation, but it > > > > I think if you know you can use the if(KCONFIG_) technique, then one > would tend to structure things so that you do it as much as possible. > Ideally you'd use CONFIG vars in Makefiles to make code go away > entirely, and if (KCONFIG_) in .c files to do conditional compilation. > > >does seem a bit risky. What happens with Kconfig variables which are > >just not known about at all with some .configs? > > > >Silly example, one could add > > > > if (KCONFIG_DVB_VES1820) > > > >to kernel/sched.c and that would work happily until someone sets DVB=n, > >in which case I assume KCONFIG_DVB_VES1820 doesn't get defined > >anywhere? > > > >A more realistic example might be using an x86-only KCONFIG_* in non-x86 > >code. > > > > Well, logically that means that all config vars are always "known", even > if they can never be defined. I don't know what the practicalities of > that are: can all Kconfig files everywhere reasonably be scanned to > produce the symbol list? When we have one configuration for the kernel and not as today where we have one configuration for each architecture (with a lot of shared files) then it is already taken care of by my (updated) patch. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
