@@ -78,6 +78,14 @@ endef
define inner-kconfig-package
+# Default values
+$(2)_MAKE ?= $$(MAKE)
+$(2)_KCONFIG_EDITORS ?= menuconfig
+$(2)_KCONFIG_OPTS ?=
+$(2)_KCONFIG_FIXUP_CMDS ?=
+$(2)_KCONFIG_FRAGMENT_FILES ?=
+$(2)_KCONFIG_DOTCONFIG ?= .config
+
# Register the kconfig dependencies as regular dependencies, so that
# they are also accounted for in the generated graphs.
$(2)_DEPENDENCIES += $$($(2)_KCONFIG_DEPENDENCIES)
@@ -88,14 +96,6 @@ $(2)_DEPENDENCIES += $$($(2)_KCONFIG_DEPENDENCIES)
# dependency expression
$(call inner-generic-package,$(1),$(2),$(3),$(4))
-# Default values
-$(2)_MAKE ?= $$(MAKE)
-$(2)_KCONFIG_EDITORS ?= menuconfig
-$(2)_KCONFIG_OPTS ?=
-$(2)_KCONFIG_FIXUP_CMDS ?=
-$(2)_KCONFIG_FRAGMENT_FILES ?=
-$(2)_KCONFIG_DOTCONFIG ?= .config
-
# Do not use $(2)_KCONFIG_DOTCONFIG as stamp file, because the package
# buildsystem (e.g. linux >= 4.19) may touch it, thus rendering our
# timestamps out of date, thus re-trigerring the build of the package.
Currently, we define the default values for kconfig-specific variables after we call into the generic package infrastructure. So far, this was totally unconsequential, because there was no kconfig variable that could influence the generic parts. But conversely, there are generic variables that do influence the kconfig part (e.g. $(2)_DIR that is used in some dependency definitions), but none that do influence the kconfig variables. However, we are going to add a new kconfig-related variable that will have an impact on the generic parts, so we will want that kconfig variable to be defined before calling into the generic infrastructure. For consistency, move all the defaults before calling the generic infra. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> --- package/pkg-kconfig.mk | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)