On 14/01/2023, Zack Weinberg wrote:
> On Sat, Jan 14, 2023, at 7:18 PM, Mike Frysinger wrote:
>> Rather than assume such coarse delays, re-use existing logic for
>> probing the current filesystem resolution. This speeds up the
>> testsuite significantly.>
[...]
> No objection to this patch in its
Mike Frysinger wrote:
Rather than assume such coarse delays, re-use existing logic for
probing the current filesystem resolution. This speeds up the
testsuite significantly. On my system, it speeds -j1 up quite a
lot -- by ~30%. While I didn't gather many samples to produce a
statistically sig
Mike Frysinger wrote:
Perl's builtin stat function returns timestamps that have 1 second
resolution. This can lead automake needlessly regenerating files
because it compares timestamps as "older than or equal to" rather
than only "older than". This is perfectly reasonable as we have
no way of k
On Sat, Jan 14, 2023, at 7:18 PM, Mike Frysinger wrote:
> Rather than assume such coarse delays, re-use existing logic for
> probing the current filesystem resolution. This speeds up the
> testsuite significantly. On my system, it speeds -j1 up quite a
> lot -- by ~30%. While I didn't gather man
On 14 Jan 2023 17:05, Karl Berry wrote:
> most of the code directly preceding & following this line use @.
> i.e. the vast majority of the current distdir logic.
>
> Yeah.
>
> If you feel like changing those @'s to AM_v_at while we're here, sounds
> good to me ... -k
i'd like to give it
Rather than assume such coarse delays, re-use existing logic for
probing the current filesystem resolution. This speeds up the
testsuite significantly. On my system, it speeds -j1 up quite a
lot -- by ~30%. While I didn't gather many samples to produce a
statistically significant distribution, m
most of the code directly preceding & following this line use @.
i.e. the vast majority of the current distdir logic.
Yeah.
If you feel like changing those @'s to AM_v_at while we're here, sounds
good to me ... -k
On 14 Jan 2023 14:52, Karl Berry wrote:
> +my $have_time_hires = eval { require Time::HiRes; };
>
> I don't object. Although if there's no speed up in practice, I wonder if
> it's worth the extra code (simple-enough though it is). -k
there's no speed up in the execution of a single process, b
On 14 Jan 2023 15:17, Karl Berry wrote:
> imo we overly rely on explicit @ in many places which can make debugging
> failures painful.
>
> FWIW, I agree. Although I see no @ here.
most of the code directly preceding & following this line use @.
i.e. the vast majority of the current distdi
imo we overly rely on explicit @ in many places which can make debugging
failures painful.
FWIW, I agree. Although I see no @ here.
if we ever get to that day, we'd use $(AM_V_at) in
this location.
Ok by me. --thanks, karl.
+my $have_time_hires = eval { require Time::HiRes; };
I don't object. Although if there's no speed up in practice, I wonder if
it's worth the extra code (simple-enough though it is). -k
-case $build in
- *-pc-msdosdjgpp) MODIFICATION_DELAY=5;;
- *) MODIFICATION_DELAY=2;;
-esac
+MODIFICATION_DELAY=$am_cv_filesystem_timestamp_resolution
Looks fantastic to me :). --thanks, karl.
The *command line option* --never-interactive was added
in version 2.5.6 (along with long command line options in general).
That version was released somewhere between 2002-04-19 and 2002-04-23;
I guess 20 years ago is long enough, barely :). Though if it's just as
easy to use the %opt
On Fri, Jan 13, 2023, at 6:33 PM, Karl Berry wrote:
>> your patch *and* consistently test flex with "--never-interactive".
>
> Making flex non-interactive sounds desirable in any case, but
> --never-interactive is not mentioned in the 2.6.0 --help message.
> Instead there is -B (--batch), although
Perl's builtin stat function returns timestamps that have 1 second
resolution. This can lead automake needlessly regenerating files
because it compares timestamps as "older than or equal to" rather
than only "older than". This is perfectly reasonable as we have
no way of knowing what file is olde
Rather than assume such coarse delays, re-use existing logic for
probing the current filesystem resolution. This speeds up the
testsuite significantly. On my system, it speeds -j1 up quite a
lot -- by ~30%. While I didn't gather many samples to produce a
statistically significant distribution, m
16 matches
Mail list logo
