kconfig: source autogenerated Kconfig.dts earlier than defconfigs #100674
Conversation
In addition to the DT_HAS_<compat>_ENABLED options, the autogenerated
Kconfig.dts file also provides the DT_COMPAT_<compat> *macros* which avoid
manually declaring them when working around the no comma limitation. Unlike
options which can be referenced before their declaration, macros MUST
be defined before their usage (otherwise, they expand to nothing ("")).
Because the defconfig files were sourced before "dts/Kconfig", it was not
possible to use the DT_COMPAT macros from shields/boards/SoC defconfig;
this is not only confusing but also suboptimal because the macros must be
defined manually.
Include "dts/Kconfig" earlier to allow usage of the DT_COMPAT macros from
shields, boards and SoC defconfig. This should have no adverse effect
since there is no reason to override the options provided by the
autogenerated Kconfig.dts anyways.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
|
|
||
| # This should be sourced early since the autogen Kconfig.dts options | ||
| # and macros may get used by shields/boards/SoC defconfig or modules. | ||
| source "dts/Kconfig" |
There was a problem hiding this comment.
Any reason why you wouldn't even source it before $(APPLICATION_SOURCE_DIR)/VERSION?
There was a problem hiding this comment.
Since the VERSION Kconfig file is not a """true""" Kconfig file (i.e., it's only supposed to provide constants), it doesn't seem necessary to provide the definitions to it:
zephyr/tests/cmake/app_version/VERSION
Lines 1 to 5 in 3b23c76
There was a problem hiding this comment.
I agree this is true for most cases, but maybe someone wants to do
EXTRAVERSION = $(shell,getextraversion,$(dt_has_compat,$(DT_COMPAT_MY_SPECIAL_IC))Far-fetched, I know.
There was a problem hiding this comment.
If we stick to what the documentation says, I don't think such a pattern is valid (notice how Kconfig is not mentioned at all).
There was a problem hiding this comment.
Sure, but it doesn't harm too, I guess? 🤷♂️
We know the contents of Kconfig.dts does not depend on the application version.
Anyway, needs an approval from assignee, I'm fine either way.
There was a problem hiding this comment.
I agree this is true for most cases, but maybe someone wants to do
EXTRAVERSION = $(shell,getextraversion,$(dt_has_compat,$(DT_COMPAT_MY_SPECIAL_IC))
The VERSION file is not only used by Kconfig but in several other places, so that would be an extremely bad idea.
|
7 participants
In addition to the
DT_HAS_<compat>_ENABLEDoptions, the autogeneratedKconfig.dtsfile also provides theDT_COMPAT_<compat>macros which avoid manually declaring them when working around the no comma limitation. Unlike options which can be referenced before their declaration, macros MUST be defined before their usage (otherwise, they expand to nothing ("")):zephyr/scripts/kconfig/kconfiglib.py
Line 2858 in 3b23c76
Because the defconfig files were sourced before
dts/Kconfig, it was not possible to use theDT_COMPATmacros from shields/boards/SoCdefconfig; this is not only confusing but also suboptimal because the macros must be defined manually.Include
dts/Kconfigearlier to allow usage of theDT_COMPATmacros from shields, boards and SoC defconfig. This should have no adverse effect since there is no reason to override the options provided by the autogeneratedKconfig.dtsanyways.This issue was encountered in #100215.