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

[Mathieu Lirzin]

demerphq <address@hidden> writes:

> On 16 Jul 2017 01:50, "Mathieu Lirzin" <address@hidden> 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 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.

IMO if the hash randomization introduces bugs in Automake this is the
sign of bad code on Automake side that need to be fixed.  I think it
would be better to fix those bugs in a case by case manner instead of
preemptively imposing an order on data structure models that are foreign
to the notion of order.

Could you run Automake test suite with those hash randomizations applied
and report the actual failures?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37