You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
cmake: kconfig: Keep symbol names sorted in EXTRA_KCONFIG_OPTIONS
This makes checksum calculation over Kconfig fragments more consistent,
which prevents writing a new `.config` when nothing really changes.
To explain this, consider the following sequence:
1. west build . -DCONFIG_XXXX=y -DCONFIG_YYYY=y
2. west build . -DCONFIG_YYYY=y
3. west build . -DCONFIG_XXXX=y
At (1), we set new values for XXXX and YYYY, so the `.config` changes.
At (2), we set a value for YYYY, but it's the same value as before, so
the `.config` doesn't get overwritten.
At (3), we set a value for XXXX, but it's the same value as before, so
the `.config` shouldn't get overwritten... but it does. What happened?
The reason is that the generated `extra_kconfig_options.conf` fragment,
which is included in the checksum calculation, was being populated using
two sets of CMake cache variables:
- past assignments, prefixed with `CLI_${KCONFIG_NAMESPACE}_`.
- new assignments, prefixed with just `${KCONFIG_NAMESPACE}_`.
Usually, past assignments would appear before new assignments, because
the default `${KCONFIG_NAMESPACE}` is CONFIG, which goes after CLI in
alphabetical order. As a result, the contents of EXTRA_KCONFIG_OPTIONS
at (1) and (2):
CONFIG_XXXX=y
CONFIG_YYYY=y
were not identical to its contents at (3):
CONFIG_YYYY=y
CONFIG_XXXX=y
resulting in a different checksum.
This is resolved by stripping out the CLI prefix first, then effectively
"mergesorting" the past and new assignments, before starting to populate
EXTRA_KCONFIG_OPTIONS.
Signed-off-by: Grzegorz Swiderski <[email protected]>
0 commit comments