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

[Tom Rini]

On Wed, Nov 05, 2025 at 09:27:07AM -0600, Ryan Eatmon wrote:
> 
> 
> On 11/5/2025 9:19 AM, Tom Rini wrote:
> > On Wed, Nov 05, 2025 at 09:13:15AM -0600, Ryan Eatmon wrote:
> > > 
> > > 
> > > On 11/5/2025 8:42 AM, Tom Rini wrote:
> > > > On Wed, Nov 05, 2025 at 03:53:16PM +0530, 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(-)
> > > > 
> > > > Isn't this what scripts/kconfig/merge_config.sh is for? No, you can't
> > > > just do "make foo_defconfig bar.config" directly, but your tooling that
> > > > knows about outside fragments can merge foo_defconfig with
> > > > /somewhere/bar.config directly.
> > > 
> > > The problem is the Yocto recipes.  There is a somewhat fixed manner in which
> > > the recipe is setup and optionally adding steps is way more invasive than
> > > just adding an option to the make command.
> > 
> > The merge_config.sh tool came from the OpenEmbedded community pushing
> > things up to the kernel, so this sounds like a problem to resolve in the
> > u-boot recipes/classes, and not something to change here. Feel free to
> > loop me in on patches / discussions over on the appropriate list(s)
> > there, thanks.
> 
> There was a recent patch to the uboot classes in yocto that allow for
> passing extra options to the make command line in for uboot.  This is
> intended not for "primary" platform configs, but for multiple alternate
> testing configs that can be built at the same time as the primary.
> Effectively, the code loops over the multiple configs in different build
> directories and configures/compiles uboot multiple times and then names all
> of the output files uniquely.
> 
> That flow has been in Yocto for a very long time and is, again, somewhat
> rigid in what it can allow for changing for each of the variant builds. It
> was designed to build different defconfigs which is what we are trying to do
> here.  But since we do not want to store the defconfigs for all of these
> variants in the uboot source itself, we need to be able to tell uboot that
> the config is in a different location other than in the uboot source.  Hence
> the most straight forward solution was a variable on the make to allow for
> specifying where to look for the out of tree defconfigs.

I think you need to fix this up in the OE side of things by taking the
new defconfigs from where they live and copying them to configs/,
assuming you're storing them somewhere as config files and not patches.
If you want to support kbuilding finding a defconfig out of tree, get
that in the kernel and then import those changes here. I do not want to
diverge from upstream on this, sorry.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251105/7b26202a/attachment.sig>