[PATCH] kconfig: Add support for out-of-tree config fragment and defconfig

[Quentin Schulz]

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 <n-francis at ti.com>
> ---
>   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