Kconfig defines symbols with unmet dependencies
|Assignee:||Martin Roth||% Done:|
Our current Kconfig setup, with the custom KCONFIG_NEGATIVES option, does not only output =n/=0 for unset booleans and numbers but also outputs booleans and numbers with unmet dependencies (i.e. symbols that are not defined at all for a given .config).
This makes Kconfig less predictable. So I ask, do we want this "feature" in the long run? For boolean symbols, we already have the IS_ENABLED() macro. For numbers, I'd argue that they are mostly used in code that should be guarded (preferably in the Makefile.inc).
OTOH, if we'd keep the current Kconfig behaviour, it would save us some ugly
#if IS_ENABLED() guards (e.g. when CONFIG_* numbers are used in headers or shared code files).
#4 Updated by Martin Roth about 2 years ago
I'll look at updating to the latest kconfig version from the kernel.
- Update Kconfig documentation
- Update Kconfig lint tool - #ifdef CONFIG_ will be valid again for bool values.
- Test updates to see what additional changes to configurations this update causes.
Maybe this change should wait until after the October release so we can have a clean cut-off point.