[PATCH] scripts: merge_config.sh: support include directives in fragments

[Tom Rini]

On Thu, Mar 19, 2026 at 05:49:35PM +0100, Julien Stephan wrote:
> Le jeu. 19 mars 2026 à 17:21, Tom Rini <trini at konsulko.com> a écrit :
> >
> > On Thu, Mar 19, 2026 at 05:14:05PM +0100, Julien Stephan wrote:
> >
> > > Many defconfig files rely on include directives to factor out common
> > > configuration. When running "make some_board_defconfig", these files are
> > > preprocessed and the includes are resolved automatically. However,
> > > merge_config.sh script currently does not handle include directives in
> > > configuration fragments.
> > >
> > > Add a preprocessing step to resolve include directives in all fragments
> > > before merging them.
> > >
> > > By default, the include search path consists of:
> > >   - the current working directory
> > >   - the fragment's directory
> > >   - the default U-Boot configs/ directory
> > >
> > > This ensures that existing defconfig files work out of the box. Additional
> > > include directories can be specified using the -I option:
> > >
> > >   ./scripts/kconfig/merge_config.sh -I <additional include dir>  configs/some_board_defconfig frag1.cfg frag2.cfg
> > >
> > > Signed-off-by: Julien Stephan <jstephan at baylibre.com>
> > > ---
> > >  scripts/kconfig/merge_config.sh | 56 +++++++++++++++++++++++++++++++++++++----
> > >  1 file changed, 51 insertions(+), 5 deletions(-)
> >
> > This forks us from the upstream version of the script, and I don't think
> > upstream will want this.
> 
> I understand. Would that help if I submit this to the kernel first?
> and see their reaction?

Honestly I don't know if the kernel or Yocto Project is the true
upstream for this script, but yes, if it's not a local addition it's
much easier to handle.

> > When I make use of this locally I do a two step:
> > - make foo_defconfig savedefconfig
> > - merge_config.sh defconfig frag1 ... fragN
> 
> That works well for defconfig inside configs/ but if you manage some
> configs outside of u-boot and they have include it won't work.

So, in my case the fragments live outside the source tree (they're in
fact just mktemp files). But this also makes me think of the issues TI
has brought up while trying to handle both "we want to test things from
Yocto builds" and "we don't want non-upstream changes". So perhaps
understanding the full use case here first would help inform the
discussion. Thanks!

-- 
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/20260319/e44efee2/attachment.sig>