From 7b81b8e482171b0484ceefea5bf28e162152925d Mon Sep 17 00:00:00 2001 From: Jan Beran Date: Wed, 18 Mar 2026 16:23:02 +0100 Subject: [PATCH] docs(kconfig): clarify how multiple renames work in sdkconfig.renames Describe how multiple renames of one deprecated option to several new options work. --- docs/en/api-guides/kconfig/configuration_structure.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/en/api-guides/kconfig/configuration_structure.rst b/docs/en/api-guides/kconfig/configuration_structure.rst index ddc1700500c..612397c04b3 100644 --- a/docs/en/api-guides/kconfig/configuration_structure.rst +++ b/docs/en/api-guides/kconfig/configuration_structure.rst @@ -79,6 +79,8 @@ The structure of the ``sdkconfig.rename`` file is as follows: * ``CONFIG_DEPRECATED_NAME CONFIG_NEW_NAME``, where ``CONFIG_DEPRECATED_NAME`` is the old config name which was renamed in a newer ESP-IDF version to ``CONFIG_NEW_NAME``. * ``CONFIG_DEPRECATED_NAME !CONFIG_NEW_INVERTED_NAME`` where ``CONFIG_NEW_INVERTED_NAME`` was introduced in a newer ESP-IDF version by Boolean inversion of the logic value of ``CONFIG_DEPRECATED_NAME``. +If there is more than one mapping for the same deprecated option name (i.e. the same deprecated option name is renamed more than once), the last occurrence is used. Configuration system will report this only if configuration report verbosity is set to ``verbose`` (e.g. via ``KCONFIG_REPORT_VERBOSITY`` environment variable). + Primary use case of this file is to ensure backward compatibility when the config name is changed in the newer ESP-IDF version. Example: