package/pkg-kconfig: move defaults before calling pkg-generic

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>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

diff --git a/package/pkg-kconfig.mk b/package/pkg-kconfig.mk
index dd727b7200ce3111d590062f57c6d1cca9214cc9..49074f92200f2bda028480863b56b10d347928bb 100644 (file)
--- a/package/pkg-kconfig.mk
+++ b/package/pkg-kconfig.mk
@@ -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.