Regarding https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13107
(from December 2012, sorry) ...
[From Mikulas]
> > config.h.in : am__configure_deps
> > echo build config.h.in
> > rm -f stamp-h1
> > touch config.h.in
[...]
> Hmm, adding a "sleep 1"
Mikulas Patocka writes:
> BTW. on Linux, high precision timestamps have really kernel-tick
> precision, not nanosecond precision.
The precision is as high as what the best hardware timer provides,
independent of the configured value of HZ.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.d
On Thu, 6 Dec 2012, Philip Guenther wrote:
> On Thu, Dec 6, 2012 at 2:02 PM, Mikulas Patocka
> wrote:
> > The apparent problem is that after make rebuilds b, it compares b's time
> > with a's time, finds that the times are equal (because a was touched just
> > before make was run) and doesn't r
On Thu, 6 Dec 2012, Philip Guenther wrote:
> Note that this problem doesn't arise on systems with high precision
> file timestamps. Many systems have provided those since the mid 90's;
> I'm appalled that the modern system that process the involved shell
> commands fast enough for this to regul
On Thu, Dec 6, 2012 at 2:02 PM, Mikulas Patocka
wrote:
> The apparent problem is that after make rebuilds b, it compares b's time
> with a's time, finds that the times are equal (because a was touched just
> before make was run) and doesn't rebuild a.
>
> I think it is a bug - when b is finished,
Hi
Try this Makefile:
---
a : b
echo build a
touch a
b : c
echo build b
touch b
---
and run this script:
touch b;sleep 1;touch a c;make
You see
"echo build b
build b
touch b"
but it doesn't remake a.
The apparent problem is that after make rebuilds b, it compares
