
On Wed, Mar 19, 2008 at 5:29 PM, Wolfgang Denk wd@denx.de wrote:
Dear Grant,
in http://news.gmane.org/gmane.comp.boot-loaders.u-boot Jean-Christophe asked to get rid of the "#ifdef CONFIG_POST" parts in the post code by using the "COBJS-$(CONFIG_POST) += " approach in the Makefile. We tried, and it didn't work.
The reason is that the Makefile assumes that the CONFIG_* variable settings in include/autoconf.mk have a value of "y", so we can collect objects to build in the "COBJS-y" make variable.
However, this is not always true. Here is what we see for example on the "lwmon5" board:
-> grep -v =y include/autoconf.mk CONFIG_POST="(CFG_POST_CACHE | CFG_POST_CPU | CFG_POST_ECC_ON | CFG_POST_ETHER | CFG_POST_FPU | CFG_POST_I2C | CFG_POST_MEMORY | CFG_POST_RTC | CFG_POST_SPR | CFG_POST_UART | CFG_POST_SYSMON | CFG_POST_WATCHDOG | CFG_POST_DSP | CFG_POST_BSPEC1 | CFG_POST_BSPEC2 | CFG_POST_BSPEC3 | CFG_POST_BSPEC4 | CFG_POST_BSPEC5)"
In this case, only CONFIG_POST is critical, but some of the other settings might show similar problems, and this is just an examplefrom a single board - there may be other, similar issues lurking with other boards.
Yeah, I was expecting as much. You're right of course that the COBJS-y trick only works if the assumption that the symbol is defined and has either an empty value or a value of '1'. Any that do not fall in this category cannot be used for "COBJS-${BLAH} += ..." statements.
This is true in the kernel also. Only CONFIG values that are bool or tristate are suitable for this type of use.
What is the suggested way to fix this? It's clear that the current string value
CONFIG_POST="(CFG_POST_CACHE | ... )"
is of no use for the decistion which files need to be compiled. My initial idea was to say that all non-empty strings should be replaced by "y", but I'm not sure about side effects; also, what to do with numeric values? Convert only non-zero values to "y"? But then, a "#define FOO 0" still means that "FOO" is defined...
No, the side effects would be too severe to blanket change all strings into "y". I see two possible solutions (both of which have already been suggested by jdl): 1. Break up CONFIG_POST bitmask and replace with CONFIG_POST_CACHE, etc. Just like was done with CONFIG_CMD. 2. Add a CONFIG_HAS_POST value that specifies that CONFIG_POST has a value.
As for having to do this again for the next one; yes we will. That's just going to be part of the pain of moving to a Kconfig style system. Not all CONFIG_ values are suitable for conditional compilation from the makefiles so where they are not we need to adapt.
Cheers, g.