On Sun, Jan 18, 2026 at 12:31:33PM +0100, Bruno Haible wrote: > > Could it be because config.h.in is in a subdirectory? In tta/configure.ac > > there > > is: > > > > AC_CONFIG_HEADERS([C/config.h]) > > > > I thought it was a bit strange for the code in tta/gnulib to be using > > tta/C/config.h as an include file (-I../../C appears on the compiler > > command line so it is found). The rules to rebuild "C/config.h" appear > > in tta/C/Makefile: > > > > $(srcdir)/config.h.in: $(am__configure_deps) > > $(AM_V_GEN)($(am__cd) $(top_srcdir) && $(AUTOHEADER)) > > $(AM_V_at)rm -f stamp-h1 > > $(AM_V_at)touch $@ > > > > It seems that this may easily not run if make does not run in that > > subdirectory early enough. > > Indeed, the explanation seems to be a combination of four factors: > > 1) You did not run "make distclean" before and "./configure" after > changing the set of Gnulib modules. > > 2) tta/configure.ac defines config.h to be in the C/ subdirectory. > > 3) The tta directory uses a "recursive" Makefile structure (i.e. > the subdirectory C/ has its own Makefile.am). > > 4) In tta/Makefile.am you define > SUBDIRS = gnulib/lib C . perl tests > Cf. [1] > > So, the fix is to > - either adopt the habit of doing "make distclean" when changing the > configuration, > - or define > SUBDIRS = C gnulib/lib . perl tests > - or put config.h in a different directory and adjust SUBDIRS similarly, > - or use a non-recursive Makefile.am (i.e. tta/Makefile.am does > 'include C/local.mk').
Thanks. I moved config.h to the top-level directory (i.e. tta/, which has its own configure.ac). I'd rather config.h.in be updated automatically, as there is more than one person committing to the repository and it wouldn't be obvious what had had happened when the build breaks in strange ways (as in this case) and running "make distclean" would be required.
