I use the gnu autools (autoconf, automake, libtool) to build a shared library and an associated binary, and a texinfo documentation.
In configure.ac, there is a version information maintained.
Now in the texinfo sources for example, I want to include the current version.
@set VERSION 0.0.1
@set UPDATED 18 June 2018
I would like to define versions only once and reuse them throughout the code base where applicable, so when bundling a release I don't end up having for example a pdf with the wrong version. Is there an established pattern for this?
I would like to define versions only once and reuse them throughout the code base where applicable, so when bundling a release I don't end up having for example a pdf with the wrong version. Is there an established pattern for this?
Sure. As you already observe, configure.ac contains version information, which in fact one generally specifies at the very top, as an argument to the AC_INIT macro. The primary function of the configure script built from it is to construct other files used in the build by filling in template files with known or discovered values. The most common files prepared that way are Makefiles, but Autotools configure scripts are in no way specific to those. In just the same way, they can prepare headers, documentation files, and pretty much any other file that can be handled as text.
For example, if you wanted to automatically encode a build or version number into your sources then you might do so by managing a header file containing that information.
To make that work, you simply name the file to be built in the argument to an AC_CONFIG_FILES macro (you may use several if you wish):
AC_CONFIG_FILES([src/version.h])
Be default, configure will expect the template for that output file to be named by adding the suffix .in (i.e. src/version.h.in). Within, reference Autoconf output variables by name, bounded by '@' characters: @VERSION@. When configure runs (or actually when the generated script config.status runs) it will create the specified output file by copying the template, substituting output variable references with discovered output variable values.
Since many cases where you want to populate version information will be similar in that the configurable part is a very small proportion of the overall file, it is often convenient to leverage features such as Texinfo's @include to isolate the configurable portions in small, separate files. The header example demonstrates this.
For texinfo in particular, however, Automake includes a special provision along these lines for version information in texinfo sources. If you name a .texi source file in a TEXINFO primary, and that file @includes one whose name matches the glob vers*.texi, then Automake will arrange for that included file to be automatically generated (unless you put in your own rules for building it). In the specific case of texinfo versioning, then, making use of that facility for generating and incorporating version data is preferable to rolling your own version file generation.