Re: [PATCH] scripts: kconfig: merge_config.sh: keep temp file in the output dir

On Wed, Jul 8, 2026 at 7:48 PM Nicolas Schier <[email protected]> wrote:
>
> On Wed, Jul 08, 2026 at 04:04:54AM -0700, Gustavo Luiz Duarte wrote:
> > merge_config.sh currently creates a temporary file in the current
> > directory. Create it under $OUTPUT instead, which allows running the
> > script against a read-only source tree.
> >
> > The default behavior is unchanged: $OUTPUT is "." so the file stays in
> > the cwd.
>
> Out of curiosity: in which situation do you need this fix?

Our build runs in a container that mounts the source tree read-only and outputs
the build artifacts into a separate rw mount point. We have our own (cruder)
flavor of merge_config.sh and I want to use the upstream script instead.

>
> >
> > Signed-off-by: Gustavo Luiz Duarte <[email protected]>
> > ---
> >  scripts/kconfig/merge_config.sh | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh
> > index f08e0863b7128..a63250d4cbf12 100755
> > --- a/scripts/kconfig/merge_config.sh
> > +++ b/scripts/kconfig/merge_config.sh
> > @@ -122,7 +122,7 @@ fi
> >
> >  MERGE_LIST=$*
> >
> > -TMP_FILE=$(mktemp ./.tmp.config.XXXXXXXXXX)
> > +TMP_FILE=$(mktemp "$OUTPUT/.tmp.config.XXXXXXXXXX")
>
> <bike-shedding>
> While this does as written in the commit message, I'd rather expected
> something like
>
>  mktemp --tmpdir="$OUTPUT" .tmp.config.XXXXXXXXXX
>
> instead.
> </bike-shedding>

I can send a v2 with --tmpdir=

>
>
> When I am reading the help text for merge_config.sh's '-O', I think we
> should adjust the default output directory as well:
>
>   -O    dir to put generated output files.  Consider setting $KCONFIG_CONFIG instead.
>
> With a read-only source tree in mind, KCONFIG_CONFIG probably has to be
> set, otherwise we'd not need to put the temporary file somewhere else.
> Might it be more consistent to use $(dirname ${KBUILD_KCONFIG}) as
> default for OUTPUT instead of '.'?

Maybe, but then, as far as I understand it, setting a custom KBUILD_KCONFIG
would lead to object files (like the conf binary and other object files) being
put into $(dirname ${KBUILD_KCONFIG}). Is that the intention?

>
> So, once again: in which situation do you need the fix?  Is it really
> sufficient as it is?

$KCONFIG_CONFIG is already derived from $OUTPUT, so the current patch is
sufficient for our read-only source tree use-case.

Thanks for the review!

Kind regards,
Gustavo