Hi Neha Malcom Francis,
On 11/5/25 11:23 AM, Neha Malcom Francis wrote:
Add support for fetching config fragments and defconfigs out-of-tree using
CONFIG_FRAGMENT_PATH and CONFIG_DEFCONFIG_PATH respectively.
Signed-off-by: Neha Malcom Francis <[email protected]>
---
scripts/kconfig/Makefile | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index f0f93c56bdb..051c801eadb 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -12,6 +12,13 @@ PHONY += xconfig gconfig menuconfig config localmodconfig
localyesconfig \
# Set SRCARCH to .. fake this Makefile.
SRCARCH := ..
+# If a config fragment file is kept in an out-of-tree path, add it to the list
+# of paths to be searched within
+CONFIG_FRAGMENT_PATH ?= $(srctree)/arch/$(SRCARCH)/configs
+
+# If a defconfig file is kept in an out-of-tree path, pick it from there
+CONFIG_DEFCONFIG_PATH ?= $(srctree)/arch/$(SRCARCH)/configs
+
ifdef KBUILD_KCONFIG
Kconfig := $(KBUILD_KCONFIG)
else
@@ -93,7 +100,7 @@ endif
endif
%_defconfig: $(obj)/conf
- $(Q)$(CPP) -nostdinc -P -I $(srctree) -undef -x assembler-with-cpp
$(srctree)/arch/$(SRCARCH)/configs/$@ -o generated_defconfig
+ $(Q)$(CPP) -nostdinc -P -I $(srctree) -undef -x assembler-with-cpp
$(CONFIG_DEFCONFIG_PATH)/$@ -o generated_defconfig
$(Q)sed -i -e 's/^[[:space:]]//' generated_defconfig
$(Q)$< $(silent) --defconfig=generated_defconfig $(Kconfig)
@@ -103,6 +110,7 @@ endif
configfiles=$(wildcard $(srctree)/kernel/configs/$@ \
$(srctree)/arch/$(SRCARCH)/configs/$@ \
+ $(CONFIG_FRAGMENT_PATH)/$@ \
We have the same path twice if using the default value now, did you mean
to replace the line just before?
If one uses the same fragment name out-of-tree than in-tree, then the
in-tree fragment and the out-of-tree fragment will both be applied I
believe? Is this something we want? If we pass an OOT path, maybe we
only want to use the OOT ones and not a mix? Additionally, because this
OOT path is in the middle of in-tree paths, whether this fragment is
applied first or last depends on the location of the in-tree fragment
(if in-tree's in a board directory, then OOT applied first, otherwise
second). Maybe we should rather have it last or first but not in the middle?
Should we have support for multiple paths for fragments? So that people
can organise their out-of-tree directory of fragments with multiple
sub-directories (e.g. per-arch or per-board)?
I would recommend NOT prefix your variables with CONFIG_ which is
usually something reserved for Kconfig options, which isn't what they
are here.
We probably also should document this new behavior somewhere in the docs.
Cheers,
Quentin
