Hi Eric, > > Also, running autoreconf produces funny results: > > > > configure.ac:155: the top level > > configure.ac:155: warning: gl_TYPE_WINT_T_PREREQ is m4_require'd but not > > m4_defun'd > > m4/gnulib-comp.m4:855: M4_INIT is expanded from... > > configure.ac:155: the top level > > configure.ac:155: warning: gl_PTHREADLIB is m4_require'd but not m4_defun'd > > m4/sched_yield.m4:9: gl_FUNC_SCHED_YIELD is expanded from... > > m4/gnulib-comp.m4:855: M4_INIT is expanded from... > > configure.ac:155: the top level > > configure.ac:155: warning: gl_PTHREADLIB is m4_require'd but not m4_defun'd > > ... > > Adding bug-gnulib to investigate this.
Fact 1: 'autoreconf' is not generally supported by GNU packages. It may work, or it may not work. Fact 2: m4 uses a variant of the 'bootstrap' script that by default puts symbolic links, rather than file copies. Since the piece of log above shows that autoreconf has passed the option "-I m4" to autoconf (inferred from the ACLOCAL_AMFLAGS in Makefile.am), it looks like some *.m4 files in there are not present or are dangling symlinks. > # M4 is single-threaded; so we can optimize gnulib code by using this: > gl_DISABLE_THREADS > AC_DEFINE([GNULIB_REGEX_SINGLE_THREAD], [1], [Define to optimize regex.]) > AC_DEFINE([GNULIB_MBRTOWC_SINGLE_THREAD], [1], [Define to optimize mbrtowc.]) > AC_DEFINE([GNULIB_WCHAR_SINGLE_LOCALE], [1], [Define to optimize mbrtowc.]) > > right after AC_PROG_CC and M4_EARLY() (the macro created by > gnulib-tool). It could be that I'm using the macros in the wrong > place, or it could be a genuine issue in the behavior of the gnulib > macros for short-circuiting decisions for a known-single-threaded app. I don't think so. More likely the problem is with the set of symlinks in m4/ and the list of file names in aclocal.m4. > But out of curiosity - but is > there a way to make the reproducible hard-code the date of the git > commit into UPDATED rather than the current date? It would still be > nice if the manual could include the release date (something that > reproducibly gets included, no matter whether I build today or a year > from now, by scraping something out of git or NEWS) Yes. I would suggest to adapt the func_version from gnulib/all-modules. Essentially it extracts the information from "git log". In the case of gnulib, it looks at the ChangeLog file. For m4, you could make it look at the doc/m4.texi file instead. Bruno
