GNU bug report logs - #13107
timestamp bug when files are created just before make is run

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Karl Berry <karl <at> freefriends.org>
Subject: bug#41843: closed (Re: bug#13107: timestamp bug when files are
 created just before make is run)
Date: Sun, 12 Jul 2020 01:24:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#13107: timestamp bug when files are created just before make is run

which was filed against the automake package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 41843 <at> debbugs.gnu.org.

-- 
13107: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13107
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Karl Berry <karl <at> freefriends.org>
To: 13107 <at> debbugs.gnu.org
Subject: Re: bug#13107: timestamp bug when files are created just before make
 is run
Date: Sat, 11 Jul 2020 19:23:45 -0600

Given the zero response, it seems undesirable to add even minor
complexity to support something which may no longer be needed.
Closing. -k

[Message part 3 (message/rfc822, inline)]

From: Karl Berry <karl <at> freefriends.org>
To: mikulas <at> artax.karlin.mff.cuni.cz
Cc: guenther <at> gmail.com, bug-automake <at> gnu.org, bug-make <at> gnu.org
Subject: Re: timestamp bug when files are created just before make is run
Date: Sat, 13 Jun 2020 19:24:51 -0600

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" after that rm -f and before the touch
    > config.h.in would work without reintroducing the issue described in
    > that explanation, no?
    > Philip Guenther

    [Mikulas again]
    Yes it fixes it, you can add "sleep 1" to automake there, that fixes
    the bug.

Does this bug still come up?
Is it worth considering adding the sleep 1 to automake after the rm -f?
All those sleeps might add up, though.

An alternative would be a variable for a command (that does nothing by
default) that could be overridden in a project that needs to worry about
this problem. That would be safe in that it would have no visible
impact, but I'm not inclined to do so unless it would actually be used.

Anyone out there who wants it? --thanks, karl.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.