bug#25629: Hrm, actually autom4te isnt part of automake, but rather autoconf.

2024-06-15 Thread Karl Berry
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 t

bug#25629: Hrm, actually autom4te isnt part of automake, but rather autoconf.

2017-07-16 Thread Mathieu Lirzin
demerphq writes: > On 16 Jul 2017 01:50, "Mathieu Lirzin" wrote: > > Can you explain what would be the benefit for Automake to have such > deterministic behavior? > > Thanks for the report. > > The most obvious reason is when debugging with something like diff > deterministic behaviour elimin

bug#25629: Hrm, actually autom4te isnt part of automake, but rather autoconf.

2017-07-16 Thread demerphq
On 16 Jul 2017 01:50, "Mathieu Lirzin" wrote: Hello Yves, demerphq writes: > Also I observe that there were previous patches to ensure most uses of > keys() were sorted. However not all of them, including diagnostics, > and various other places where the key order could be exposed to a > user.

bug#25629: Hrm, actually autom4te isnt part of automake, but rather autoconf.

2017-07-15 Thread Mathieu Lirzin
Hello Yves, demerphq writes: > Also I observe that there were previous patches to ensure most uses of > keys() were sorted. However not all of them, including diagnostics, > and various other places where the key order could be exposed to a > user. > > Attached is a patch that I believe fixes an

bug#25629: Hrm, actually autom4te isnt part of automake, but rather autoconf.

2017-02-05 Thread demerphq
Also I observe that there were previous patches to ensure most uses of keys() were sorted. However not all of them, including diagnostics, and various other places where the key order could be exposed to a user. Attached is a patch that I believe fixes any remaining uses of unsorted keys. I took