From 29deb3f6178d776cdaaf3058d06c7d8bd142445f 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 1d01c5dd06..235a3c1068 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: