On Sat, 13 Apr 2002 11:04:35 -0500, Michael Elizabeth Chastain <[EMAIL PROTECTED]> wrote: >Keith Owens writes: >> IMHO, split-include needs to recognise the first time that a variable >> is seen (no previous split config file) and the variable is 'n'. For >> this case, split-include should not create the file, i.e. treat it as >> if the variable was still suppressed. > >That assumes that all C code behaves the same on CONFIG_DEP="" >and CONFIG_DEP="n".
There is no difference in autoconf.h between a suppressed variable (CONFIG_DEP="", no reference in autoconf) and a variable that is visible but set to n (CONFIG_DEP="n", explicitly undefined). In both cases the variable is undefined. C code cannot distinguish between a suppressed variable and one that is set to n. The problem is that these cases give different timestamps after split-include, causing recompiles. Changing CONFIG_KERNEL_DEBUG from n to y, split-include forces 280+ recompiles because of the newly visible dependent variables, even though they are set to n. Comparing vmlinux before and after the 280+ recompiles, they are identical except for the build timestamp. There is a difference between the two cases for Makefiles, because make reads .config directly, not autoconf.h. If a makefile incorrectly does ifdef CONFIG_FOO then it gets different results on suppressed and visible variables. Any make code that does ifdef CONFIG_xxx is broken, it should be doing ifeq ($(CONFIG_xxx),y) if the variable is known to be boolean, or the more general ifneq ($(subst n,,$(CONFIG_xxx)),) which handles both tristate and boolean. There are some broken makefiles, but they will not be affected by a change to split-include because make runs directly off .config. _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
