Should be backported to 8.0 and 7.8 branch.

This usually happens pre RC1:
https://github.com/OSGeo/grass/blob/main/doc/howto_release.md#update-of-configure-base-files

I had considered it then skipped it - if we go for a 8.0.1RC2 then it could be backported but if not urgent I'd prefer 8.0.2 and 7.8.8.

This usually happens pre RC1: https://github.com/OSGeo/grass/blob/main/doc/howto_release.md#update-of-configure-base-files

I had considered it then skipped it - if we go for a 8.0.1RC2 then it could be backported but if not urgent I'd prefer 8.0.2 and 7.8.8.

Perfectly fine for me, not at all urgent.

The autoconf2.69 step is missing, see
https://github.com/OSGeo/grass/blob/main/doc/howto_release.md#update-of-configure-base-files

I'm not quite sure what you mean, running autoconf doesn't make any difference.

I'm not quite sure what you mean, running autoconf doesn't make any difference.

I see - mostly it does but apparently it doesn't affect configure in this case. Sorry for the confusion.

I'm not quite sure what you mean, running autoconf doesn't make any difference.

I see - mostly it does but apparently it doesn't affect configure in this case. Sorry for the confusion.

No worries :-) As far as I understand it, the config.guess and config.sub are read/run by configure, but not altering the configure file.

Looking at the history of configure it appears that sometimes also this file is affected (e.g., d57f409, 1774674,
fcffbb5), i.e. to be updated with autoconf.

Looking at the history of configure it appears that sometimes also this file is affected (e.g., d57f409, 1774674,
fcffbb5), i.e. to be updated with autoconf.

Non of those changes to configure are caused by updating config.guess or config.sub.
The first two are patches (the same applied twice) to autoconf 2.13:

for ac_declaration in \
    ''\
    '#include <stdlib.h>' \
    'extern "C" void std::exit (int) throw (); using std::exit;' \
    'extern "C" void std::exit (int); using std::exit;' \
    'extern "C" void exit (int) throw ();' \
    'extern "C" void exit (int);' \
    'void exit (int);'
 do
...

(see eg. https://git.rockylinux.org/staging/rpms/autoconf213/-/blob/r8/SOURCES/autoconf-2.13-c++exit.patch or https://bugzilla.redhat.com/show_bug.cgi?id=18829)

The third is a caused by a previous change in aclocal.m4 without updating configure.

Agreed. But just for the future procedure: shall we treat these updates (config.* vs autoconf) separately? Then the release procedure needs an update.

Agreed. But just for the future procedure: shall we treat these updates (config.* vs autoconf) separately? Then the release procedure needs an update.

I think so, the config.* files should/may be updated before RC release.
In addition, it doesn't hurt running autoconf, to see if there are any patches, or other inconsistencies (like the above mentioned case of aclocal.m4). And if there are any patches, they should be added to configure.in too.