On 16 Jul 2017 01:50, "Mathieu Lirzin" <m...@gnu.org> wrote:
Hello Yves, demerphq <demer...@gmail.com> 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 any remaining uses of unsorted keys. > > I took the policy that automake is not performance sensitive, at least > at the level of sorting keys, and that sorting something that is not > strictly necessary does no harm. > > I admit I have not been able to properly test all of these changes, > but superficial testing does not reveal any issues. > > Anyway, sorry for the misleading original bug-report. > > Cheers, > Yves 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 eliminates spurious changes. Also having a deterministic and well understood ordering rule eliminates any concern that order might matter, and that a bug or whatnot was due to a different order (regardless of whether such a concern actually makes sense.) also sorting output lists makes them more readable. I don't know how well tested Automake is but I would assume deterministic hash order would help there too. Also note that Prior to hash randomization the key order would have been consistent between multiple runs. Thus when randomization was introduced the behaviour of Automake changed and effectively regressed. Sorting keys effectively restores the original behaviour. Cheers Yves
