Bruno Haible via Gnulib discussion list [2025-01-22 21:53 +0100] wrote: > Spent the day thinking through the concepts and fixing all the problems.
Thank you for working on this! I'm facing the following issues in adapting my project to the new git-version-gen guidelines. I've pushed a stripped-down version to the following Git repository in the hope that it serves as a useful common example: https://git.sr.ht/~blc/foo Its first commit targets Gnulib of 2025-01-19, and is tagged for git-version-gen to work. The second commit adapts to the new git-version-gen guidelines of Gnulib 2025-01-23. The third commit tries to work around what seem to be unexpected snags in switching to the new guidelines. > +One such propagated value is > +the value of the Automake-defined variable @code{$(VERSION)}. > +(There is also the Autoconf-defined variable @code{$(PACKAGE_VERSION)}, > +but nothing except Automake ought to use it.) Why ought nothing else use PACKAGE_VERSION? I understand that projects using Automake can use VERSION in place of PACKAGE_VERSION, but I'm not aware of anything analogous to other PACKAGE_* definitions, such as PACKAGE_STRING or PACKAGE_URL. > +The recommended code pattern is > +@example > +AC_INIT > +AC_CONFIG_SRCDIR([@var{unique-file-in-source-dir}]) > +AC_CONFIG_AUX_DIR([build-aux]) > +VERSION_NUMBER=`cd $srcdir \ > + && build-aux/git-version-gen .tarball-version \ > + | sed -e 's/dirty$/modified/'` > +gl_INIT_PACKAGE([@var{package}], [$VERSION_NUMBER]) > +AM_INIT_AUTOMAKE([@var{options}]) > +@end example AC_INIT is documented as taking two mandatory arguments. - One small consequence of following this pattern is that uses of PACKAGE_* variables have to be adapted. Switching from PACKAGE_NAME and PACKAGE_VERSION to PACKAGE and VERSION, respectively, is straightforward (as is adapting to the now-empty PACKAGE_STRING). But it's unclear how I can continue to affect e.g. PACKAGE_BUGREPORT or PACKAGE_URL. The following commentary for Autoconf's AC_INIT definition in lib/autoconf/general.m4 suggests that one can define the AC_PACKAGE_* macros before invoking AC_INIT: # AC_INIT([PACKAGE, VERSION, [BUG-REPORT], [TARNAME], [URL]) # ---------------------------------------------------------- # ... # If BUG-REPORT is omitted, do without (unless the user previously # defined the m4 macro AC_PACKAGE_BUGREPORT). # ... But I can't find this documented anywhere (except for the analogous case of AT_INIT requiring AT_PACKAGE_BUGREPORT to already be defined), and it's certainly less ergonomic than calling AC_INIT with two or more arguments. From reading Gnulib's m4/init-package-version.m4 commentary I can appreciate that it's a delicate dance, but I wish Gnulib's docs would continue leading me in this dance :). - A slightly bigger consequence of this pattern is the change in name of the Gnulib library under the lib/ directory. What was previously: src_libfoo_la_LIBADD = $(top_builddir)/lib/libfoo.la is now: src_libfoo_la_LIBADD = $(top_builddir)/lib/lib.la IIUC this is because Gnulib's build-aux/bootstrap looks at AC_INIT arguments in order to construct the gnulib-tool --lib argument. - The biggest consequence is that 'make' fails after editing e.g. configure.ac: 0. git clean -fdx 1. export GNULIB_SRCDIR='/dir/of/gnulib' 2. ./bootstrap --no-git --skip-po 3. ./configure 4. echo >> configure.ac 5. make CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash '/home/blc/src/foo/build-aux/missing' aclocal-1.16 configure.ac:10: error: AC_INIT should be called with package and version arguments /usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from... configure.ac:10: the top level autom4te: error: /usr/bin/m4 failed with exit status: 1 aclocal-1.16: error: autom4te failed with exit status: 1 make: *** [Makefile:1116: aclocal.m4] Error 1 > +The second such old code pattern > +is to invoke @code{git-version-gen} at @code{autoconf} time: > +@example > +AC_INIT([@var{package}], > + m4_esyscmd([build-aux/git-version-gen .tarball-version \ > + | sed -e 's/dirty$/modified/'])]) > +AC_CONFIG_SRCDIR([@var{unique-file-in-source-dir}]) > +AC_CONFIG_AUX_DIR([build-aux]) > +AM_INIT_AUTOMAKE([@var{options}]) > +@end example Should the Autoconf manual be updated as well? This pattern is still described in (info "(autoconf) Initializing configure"). Thanks, -- Basil
