cvs commit: src/gnu/usr.bin/cc/cc_tools Makefile

[Ruslan Ermilov]

On Sun, May 20, 2007 at 07:08:37PM -0400, Garance A Drosehn wrote:
>  At 10:27 AM +0400 5/20/07, Ruslan Ermilov wrote:
> >
> > It sometimes happens when the date/time are not being set
> > properly, so that the tools are mistakenly rebuilt again
> > at an inappropriate time when in the foreign environment
> > of the target -- the problem is usually understood better
> > when building for another CPU architecture and hitting it.
> > I think this was an inappropriate commit to make, unless
> > the problem can be reproduced.  I have upgraded several
> > i386's and amd64's without a problem.
> 
>  Is there any way we could detect the clock-skew problem?  This keeps
>  coming up, year-after-year, for many different people, including
>  very experienced developers.  And when it does come up, it is
>  either:  (1) totally safe, and thus unnoticed, or (2) screws up
>  someone in the middle of some major upgrade, thus causing great
>  angst and gnashing of teeth.
> 
>  It would be nice if we could come up with a reliable check for the
>  problem.
> 
This came up before, and I have a rudimentary patch for this
that should cover most of the cases, leaving a backdoor for
shooting in the foot, but i'm uncertain about how to properly
address the local/remote date/time mismatch issues I mention
here.

For example, with the below check added, if you "cvs update"
your src/ from a remote repo, and your machine is lagging
time by one minute, you'll end up with a file whose modification
time is set to the future time, from your machine clock's POV.
Also, the one-second granularity could sometimes be annoying.

On Thu, Dec 01, 2005 at 08:47:03PM +0200, Ruslan Ermilov wrote:
> I considered doing this in make(1) a while ago, but have come
> to a conclusion it's not quite safe.  For example, I often
> "cvs update" from remote repositories, and that sets modification
> time to that of the repository machine (probably only if it's a
> new file, I don't recall all the conditions now, or it might
> have been NFS-mounted src/ or repo).
> 
> This has the granularity of one second, i.e., "touch Makefile;
> make -n all" will falsely trigger the check:
> 
> %%%
> Index: Makefile
> ===================================================================
> RCS file: /home/ncvs/src/Makefile,v
> retrieving revision 1.325
> diff -u -r1.325 Makefile
> --- Makefile	28 Nov 2005 11:14:36 -0000	1.325
> +++ Makefile	1 Dec 2005 18:43:12 -0000
> @@ -159,6 +159,10 @@
>  .MAIN:	all
>  
>  STARTTIME!= LC_ALL=C date
> +CHECK_TIME!= find ${.CURDIR}/Makefile -mtime -0
> +.if ${CHECK_TIME} == "${.CURDIR}/Makefile"
> +.error check your date/time: ${STARTTIME}
> +.endif
>  
>  .if defined(HISTORICAL_MAKE_WORLD) || defined(DESTDIR)
>  #
> %%%


Cheers,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20070521/f616efc0/attachment.pgp