Hi,
On 6/12/24 08:00, Karl Berry wrote:
Any other ideas?
A horrible one: split the test so it can be performed in parallel with
others -- upper half starts the sleep in the background, lower half
waits for it to complete.
Simon
At some point, it becomes unreasonable to burden common platforms with
delays that only support relatively obscure and obsolete platforms.
Configure scripts already have a bad reputation for wasting time. Even
if they are faster than editing a custom makefile, they are idle instead
of active
Karl Berry wrote:
bh> Seen e.g. on NetBSD 10.0.
Which doesn't support subsecond mtimes?
jb> Maybe the best answer is to test for subsecond timestamp
granularity first, and then only do the slow test to distinguish
between 1-second and 2-second granularity if the subsecond
gr
Karl Berry wrote:
> The simple change is to omit the make test if we are at resolution 1.
> That will save 4 seconds.
It should save 6 seconds. Because it goes like this:
- Test whether 0.01 sec works.
- Test whether 0.1 sec works.
- If not, set the variable to 2, because that's the worst ca
Maybe this is a silly question, but, is there a reason why this test
needs to be performed in every single package that uses Automake?
I was under the impression that the purpose of this test was merely
to speed up running Automake's own test suite.
There are other packages that h
Hi Christoph,
https://www.sovereigntechfund.de/programs/bug-resilience
Thanks for bringing this up.
> Our partner 'Neighbourhoodie Software' provides a variety
> of types of contributions to participating projects to
> address known issues,
If that means providing patches fo
bh> Seen e.g. on NetBSD 10.0.
Which doesn't support subsecond mtimes?
jb> Maybe the best answer is to test for subsecond timestamp
granularity first, and then only do the slow test to distinguish
between 1-second and 2-second granularity if the subsecond
granularity test gives
Date: Sat, 08 Jun 2024 00:27:39 +0200
From: Bruno Haible
To:
Subject: 1.16.90 regression: configure now takes 7 seconds to start
[I'm writing to automake@gnu.org because bug-autom...@gnu.org
appears to be equivalent to /dev/null: [...]
It seems this has been fixed, what
