Cannot disable Kconfig options from cmake command line

[aescolar]

Describe the bug
When setting a boolean option to "n" as an argument when invoking cmake the option is lost, but setting them to "y" works as expected.
So for ex. :
cmake ../samples/hello_world/ -DBOARD=native_posix -GNinja -DCONFIG_NATIVE_POSIX_SLOWDOWN_TO_REAL_TIME=y
works as expected, while
cmake ../samples/hello_world/ -DBOARD=native_posix -GNinja -DCONFIG_NATIVE_POSIX_SLOWDOWN_TO_REAL_TIME=n
will not dump the option in CMakeCache.txt, and when calling ninja, cmake will be rerun, and the .config file will be regenerated, forgetting the selection.

To Reproduce
Steps to reproduce the behavior:

1. mkdir build; cd build
2. cmake ../samples/hello_world/ -DBOARD=native_posix -GNinja -DCONFIG_NATIVE_POSIX_SLOWDOWN_TO_REAL_TIME=n
3. #At this point, zephyr/.config contains (as it should) a # CONFIG_NATIVE_POSIX_SLOWDOWN_TO_REAL_TIME is not set
   But CMakeCache.txt does not contain a line like CONFIG_NATIVE_POSIX_SLOWDOWN_TO_REAL_TIME:STRING=n
4. ninja
5. #You can see that cmake is rerun [0/1] Re-running CMake..., and zephyr/.config now has that option set to yes.

Expected behavior

• in step 3 before CMakeCache.txt would contain a line like CONFIG_NATIVE_POSIX_SLOWDOWN_TO_REAL_TIME:STRING=n
• after calling ninja in the steps before, cmake would not be rerun, and the .config file would not be regenerated like if that command line option was never provided.

Impact
Not possible to disable configuration options from the command line when invoking cmake.

Environment (please complete the following information):

• OS: Ubuntu 18.04
• 3980e0c (master)

( The feature was introduced in #8487 )

[SebastianBoe]

Hi, the root cause is a bug in extensions.cmake:import_kconfig.

import_kconfig assumes that "#" denotes a comment. But in actuality it can denote a value assignment.

To avoid increasing the complexity of import_kconfig I believe it would be best to resolve this by resolving #5443. Then it is not longer an incorrect assumption that "#" denotes a comment in Zephyr.

[nashif]

not sure what the use case is, but I do not think this is a bug per se and we should not enable this type of overrides, this can cause all kind of inconsistencies and dependency problems. If you want to disable an option, either use an overlay or disable the option directly in the project prj.conf

[aescolar]

not sure what the use case is, but I do not think this is a bug per se and we should not enable this type of overrides

This works fine now for enabling bool options, or setting other options. The use case is quickly enabling disabling an option without the need to modify files. So the only issue is unsetting bools
#5723

[aescolar]

Reopening. It is functionality which was added and was meant to work. It is not too critical to fix it, and therefore it can just stay (as it was) as low prio.

[nashif]

when did it work? which commit did break it?

[aescolar]

Everything but setting a bool to "n" worked since #8487 (AFAIK). It was not broken by any commit, it was just not thoroughly enough tested, so we did not realized this case did not work as expected when it got in.

[nashif]

Ok, so it never worked.
Now back to my previous comment, I do not think we should support this, there is no way we can guarantee that =n would work for every option and this might be confusing and might provide conflicting results based on the baseline configuration used.

[aescolar]

there is no way we can guarantee that

Well.. at least in my simple mind, not more than we can guaranty it when setting it in an overlay file..
( zephyr/misc/generated/extra_kconfig_options.conf being mostly just an overlay, or? )
I mean, this is just a way for developers who know what they are doing to quickly change an option (say compile without optimizations, or with coverage, or with some priority changed). Of course that option may conflict with others, that's why we have Kconfig nicely telling us so when they do ; And zephyr/.config showing us how everything really ended.

https://github.com/zephyrproject-rtos/zephyr/pull/8487/files

[aescolar]

As this never actually worked, maybe instead of considering it a bug, we should consider it an enhancement

[ulfalizer]

There's a new setconfig utility in upstream Kconfiglib now by the way. Maybe it could be useful here.

Used like this:

$ setconfig FOO=n BAR="string value"

It will print a warning/error if the value can't be set, e.g. due to missing symbols or unsatisfied dependencies.

[57300]

Hi, I just found this old issue. It should be resolved as of cb46ed6, so I'm closing it.