Bruno Haible <br...@clisp.org> writes: > Sam James wrote: >> For reasons once might be able to guess, I'm currently playing with >> "known" M4 macros vs unseen serials and such. >> >> At the moment, my tool uses the format described at >> https://www.gnu.org/software/automake/manual/html_node/Serials.html. >> >> My reading of it implies that the use in e.g. m4/build-to-host.m4 >> as '# build-to-host.m4 serial 3' isn't valid (I would expect "# serial 3 >> build-to-host.m4" or similar, closest analogue). >> >> If I grep for serial in gnulib, I see a mix of both the format I >> expected and this other format which uses the macro name too. >> >> Are both formats valid (I know it's largely a convention)? > > The handling of the 'serial' lines happens in $PREFIX/bin/aclocal, > lines 149..151: > > # Match a serial number. > my $serial_line_rx = '^#\s*serial\s+(\S*)'; > my $serial_number_rx = '^\d+(?:\.\d+)*$'; > > and lines 604..709. This means, the format is a line that starts > with '#', followed by optional whitespace, then the word 'serial', > then some whitespace, then some consecutive non-whitespace characters. > The latter must consist only of digits and dots and start with a digit > (see also the error message at line 611: > "expecting a version string with only digits and dots"). > > So, a line > # build-to-host.m4 serial 3 > has no effect. > > The format with fractional digits is, of course, useful for git branches, > where we can have > # serial 4.1 > if on the 'master' branch the serial 4 and 5 already exist. > >> Is there a >> reason for the apparent inconsistency in format used within e.g. gnulib? > > Yes: In some cases (see $PREFIX/bin/aclocal, lines 910..936) the generated > aclocal.m4 file does not contain a reference to the .m4 file but its entire > contents. In order to make it clear which .m4 file is where in the aclocal.m4 > file, I added a comment indicating the original file name. But having not > read the Automake documentation, I thought I could merge it with the 'serial' > line... > >> I'll inevitably have to try deal with both formats as they will be in >> the wild anyway, but got curious ;) > > No, you need to deal only with the valid format, not with the ineffective one. > > I am applying these three patches:
Thank you very much Bruno -- for the quick fix, explanation, and prompt reply. Cheers! At a glance, it looks like gettext's m4/fixautomake.m4 at least might be affected. There's some in GNU Autoconf's testsuite, but that requires further inspection in case it's deliberately testing the parsing. I should really have all the GNU projects in one directory so I can easily grep in future. > [...] best, sam
signature.asc
Description: PGP signature
