On Sat, Feb 12, 2022 at 2:07 AM Mike Frysinger <vap...@gentoo.org> wrote: > The current code sleeps at least 1 second to make sure the generated > files are strictly newer than the source files. It does this for a > few reasons: POSIX only guarantees that `sleep` accept integers, and > filesystems have a history (c.f. Windows) of bad timestamp resolution. > > For the first part, we can easily probe sleep to see if it accepts a > decimal number with a fractional part -- just run `sleep 0.001`. > > For the second part, we can create two files and then run sleep in a > loop to see when one is considered newer than the other. > > For many projects, this 1 second delay is largely amortized by the > rest of the configure script. Autoconf lends itself to being both > large & slow. But in projects with many smallish configure scripts > with many cached vars, the time to rerun is dominated by this single > sleep call. For example, building libgloss against a compiler with > many (60+) multilib configurations, we see: > [Using sleep 1] > $ time ./config.status > real 2m28.164s > user 0m33.651s > sys 0m9.083s > [Using sleep 0.1] > $ time ./config.status > real 0m39.569s > user 0m33.517s > sys 0m8.969s > > And in case anyone wonders, going below 0.1s doesn't seem to make a > statistically significant difference, at least in this configuration. > It appears to be within "noise" limits. > [Using sleep 0.001] > $ time ./config.status > real 0m39.760s > user 0m33.342s > sys 0m9.080s > > * m4/sanity.m4: Determine whether `sleep` accepts fractional seconds. > Determine (roughly) the filesystem timestamp resolution. Use this to > sleep less when waiting for generated file timestamps to update.
Nice work. I looked through the patch and didn't see any issue.
