GNU bug report logs - #73926
29.4; *-autoloads.el generation not reproducible

Previous Next

Full log

Message #13 received at 73926-done <at> debbugs.gnu.org (full text, mbox):

From: Xiyue Deng <manphiz <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73926-done <at> debbugs.gnu.org
Subject: Re: bug#73926: 29.4; *-autoloads.el generation not reproducible
Date: Mon, 21 Oct 2024 14:31:06 -0700

Hi Eli,

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Xiyue Deng <manphiz <at> gmail.com>
>> Date: Mon, 21 Oct 2024 01:00:14 -0700
>> 
>> I was trying to debug a reproducibility test failure on muse-el in
>> Debian Salsa CI reprotest[1].  It looks like that the contents of the
>> generated autoload file depends on the input sequence of files and
>> directories, and it looks like the `loaddefs-generate' doesn't enforce
>> such a sequence to be consistent.
>> 
>> I have provided a patch (attached) to sort the input directories and
>> files in an attempt to fix this reproducibility issue.
>
> Did you time the modified code wrt the original one, especially when
> generating loaddefs for the entire Emacs tree?  If the performance hit
> is significant, we'd probably want to make this behavior optional,
> like the other measures in Emacs that are meant to produce more
> reproducible builds.
>
> Also, AFAIK on MS-Windows directory-files produces a sorted list by
> default (just in the reverse order), so in that case calling 'sort' is
> not needed in the first place.
>
> I also wonder whether this will produce the same order on different
> operating systems, what with the file-encoding being a factor.
>

It looks like my previous test was actually incorrect and turned out
this patch on Emacs didn't actually fix the specific issue for muse-el.
So I'd like to drop this for now until I have a real fix for muse-el
first.

>> --- a/lisp/emacs-lisp/loaddefs-gen.el
>> +++ b/lisp/emacs-lisp/loaddefs-gen.el
>> @@ -596,9 +596,13 @@ instead of just updating them with the new/changed autoloads."
>>                       (concat "\\`[^=.].*" (regexp-opt tmp t) "\\'")))
>>  	 (files (apply #'nconc
>>  		       (mapcar (lambda (d)
>> -				 (directory-files (expand-file-name d)
>> -                                                  t files-re))
>> -			       (if (consp dir) dir (list dir)))))
>> +				 (sort
>> +				  (directory-files (expand-file-name d)
>> +						   t files-re)
>> +				  'string<))
>
> Isn't string< the default when 'sort' is called to sort strings?
>

Yes, actually `directory-files' should have already sorted the results
using 'string-lessp as the documentation pointed out, so this sort is
not necessary.  The one with the dir may worth considering, but will
test more before resubmitting.

> Thanks.

-- 
Regards,
Xiyue Deng

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.