On Sun, Jan 18, 2026 at 01:14:46PM +0100, Bruno Haible wrote:
> Gavin Smith wrote:
> > I moved config.h to the top-level directory (i.e. tta/, which
> > has its own configure.ac).
>
> And does it fix the issue (without modifying SUBDIRS)? That is,
> after
> $ ./autogen.sh
> $ ./configure
> $ make
> $ cd tta
> $ touch config.h.in
> does
> $ make
> update config.h *before* recursing into gnulib/lib/ ?
>
> Bruno
Yes, it seems to:
$ cd tta
$ touch config.h.in
$ make | tee make-log
rm -f stamp-h1
cd . && /bin/bash ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
make all-recursive
make[1]: Entering directory '/home/g/src/texinfo/GIT/tta'
Making all in gnulib/lib
make[2]: Entering directory '/home/g/src/texinfo/GIT/tta/gnulib/lib'
make all-recursive
make[3]: Entering directory '/home/g/src/texinfo/GIT/tta/gnulib/lib'
make[4]: Entering directory '/home/g/src/texinfo/GIT/tta/gnulib/lib'
make[4]: Nothing to be done for 'all-am'.
make[4]: Leaving directory '/home/g/src/texinfo/GIT/tta/gnulib/lib'
make[3]: Leaving directory '/home/g/src/texinfo/GIT/tta/gnulib/lib'
make[2]: Leaving directory '/home/g/src/texinfo/GIT/tta/gnulib/lib'
Making all in C
make[2]: Entering directory '/home/g/src/texinfo/GIT/tta/C'
make all-am
...
If it were otherwise, I expect the problem of out-of-date config.h
would have occurred very often with packages with subdirectories.
In tta/Makefile.in, the "all" target depends on config.h.
all: config.h
$(MAKE) $(AM_MAKEFLAGS) all-recursive
So does the "all-am" target:
all: config.h
$(MAKE) $(AM_MAKEFLAGS) all-recursive
It's possible that running "make" with some other target wouldn't
update config.h.in, but this is much less likely to be a problem.