bug#25629: closed (Automake output non-deterministic when used with later Perls)

[GNU bug Tracking System]

Your message dated Sat, 15 Jun 2024 19:18:43 -0600
with message-id <202406160118.45G1IhWQ586894@freefriends.org>
and subject line Re: bug#25629: Hrm, actually autom4te isnt part of automake, 
but rather autoconf.
has caused the debbugs.gnu.org bug report #25629,
regarding Automake output non-deterministic when used with later Perls
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
25629: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25629
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> Automake output non-deterministic when used with later Perls
>
>
>
>
> Date: 
>
> Mon, 6 Feb 2017 03:32:11 +0100
>
>
>
>
> Some time back I switched Perl to using a randomly seeded hash
> function. (I am a core perl committer, and I do a lot of work on its
> hash function.)
>
> A consequence of this is that default output from tools like
> Data::Dumper is non-deterministic, meaning output files under source
> control, etc, change unnecessarily every time.
>
> At least part of the automake toolset is affected, for instance autom4te.
>
> For autom4te a simple solution is to add:
>
> $Data::Dumper::Sortkeys = 1;
>
> to the script. This seems to fix the problem I was observing, but an
> audit of the use of  the "keys" function to ensure that any such use
> for output is sorted will eliminate this class of errors.
>
> I would be happy to put together a pull request, or a patch if you
> could point me to the relevant repository. (Which does not appear to
> be documented in the installed versions of automake, although I may
> have overlooked it.)
>
> I am sorry I cannot give a better reproduction description than this:
>
> while hacking the "dieharder" package I observed that after running
> "autoreconf -i" that the file ./autom4te.cache/requests file changed
> in ways that it should not have. Opening the file I observed it
> contains output clearly from the Perl Data::Dumper module, I then made
> the patch to autom4te described above, and observed that after running
> "autoreconf -i" again the output was sorted, and that after running it
> yet again the file was unchanged.
>
> Classic unsorted use of undefined hash order bug that we had to do a
> lot of cleanup in the Perl world around the time of Perl 5.10
>
> Thanks,
> Yves
>
>
>
> -- 
> perl -Mre=debug -e "/just|another|perl|hacker/"
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#25629: Hrm, actually autom4te isnt part of automake, but rather autoconf.
>
>
>
>
> Date: 
>
> Sat, 15 Jun 2024 19:18:43 -0600
>
>
>
>
> Hi Yves - back in 2017 you sent a patch to sort keys in automake:
>
>     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25629
>     Attached is a patch that I believe fixes any remaining uses of
>     unsorted keys.
>
> I've now applied this, with the exception of
> a) the cases that had already been done in the meantime,
>
> b) gendocs.sh and gitlog-to-changelog, which are maintained in gnulib
> (I forwarded the changes there and they have been applied), and
>
> c) help2man, which is maintained separately; I would have forwarded that
> change to bug-help2man@gnu.org except that as far as I can see this is a
> case where truly no sorting is needed. It's purely an internal
> assignment:
> --- a/doc/help2man
> +++ b/doc/help2man
> @@ -204,7 +204,7 @@ while (@opt_include)
>  # Compress trailing blank lines.
>  for my $hash (\(%include, %append))
>  {
> -    for (keys %$hash) { $hash->{$_} =~ s/\n+$/\n/ }
> +    for (sort keys %$hash) { $hash->{$_} =~ s/\n+$/\n/ }
>  }
>  
>  sub get_option_value;
>
> So I'm closing the bug.
>
> Belated thanks for the contribution.
> (And Sam, thanks for unearthing this and bringing it up again.)
>
> Happy hashing,
> karl
>
>
> --- End Message ---