bug#70410: Fwd: [PATCH] gotools: Workaround non-reproduceability of automake

[Nick Bowler]

On 2024-04-17 11:55, Karl Berry wrote:
>     so whether it is
>     @NATIVE_FALSE@install-exec-local:
>     @NATIVE_FALSE@uninstall-local:
>     or
>     @NATIVE_FALSE@uninstall-local:
>     @NATIVE_FALSE@install-exec-local:
>     depends on some hash table traversal or what.
> 
> Thanks for the report. Any chance of a Makefile.am that can reproduce
> the problem? I wonder if it's related to the @NATIVE_FALSE@ somehow.
> 
> Looking at automake.in, it's not obvious to me where a list is failed to
> be sorted. Those -local targets aren't generated by automake itself, so
> far as I can see. --thanks, karl.

Code like the above is generated by Automake when -hook or -local
targets are defined within the "true" side of an Automake conditional,
but not in the "false" side, for example:

  % cat >configure.ac <<'EOF'
AC_INIT([test], [0])
AM_INIT_AUTOMAKE([foreign])
AM_CONDITIONAL([NATIVE], [:])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF
  % cat >Makefile.am <<'EOF'
if NATIVE
install-data-local: ;
install-exec-local: ;
uninstall-local: ;
dist-hook: ;
all-local: ;
endif
EOF
  % autoreconf -is
  % grep NATIVE_FALSE Makefile.in
@NATIVE_FALSE@dist-hook:
@NATIVE_FALSE@all-local:
@NATIVE_FALSE@install-data-local:
@NATIVE_FALSE@install-exec-local:
@NATIVE_FALSE@uninstall-local:

With an older Automake (1.12.6), the order of these generated targets is
easily seen to be inconsistent.  But with a current version of Automake
(1.16.5) the order seems to be always the same.  So I wonder if this is
reporting an issue that was long ago already fixed in Automake...

Cheers,
  Nick