Date: Mon, 13 Oct 2014 14:59:03 +0200 From: Stefan Esser <se@freebsd.org> To: Matthias Apitz <guru@unixarea.de> Cc: freebsd-hackers@freebsd.org Subject: Re: gmake && file time precision of 1 second Message-ID: <543BCC97.7080608@freebsd.org> In-Reply-To: <20141013092018.GA2737@unixarea.DDR.dd> References: <20141013092018.GA2737@unixarea.DDR.dd>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 13.10.2014 um 11:20 schrieb Matthias Apitz: > > Hello, > > I have a large project where a shell script fires up > gmake runs in subdirs as: > > for dir in src norm print ....; do > cd $dir > gmake > cd .. > done > > in each subdir *.c are compiled to *.o and the resulting *.o are ar'ed > into all the same lib.a; based on normal Makefile rules like: > > SRCS = f1.c f2.c > OBJS = $(SRCS:.c=.o) > > .c.o: > $(CC) -c ... $*.c > > lib.a:: $(OBJS) > $(AR) $@ $(OBJS) > > > after moving to a faster server it turned out that gmake sometimes forget > to ar the *.o into the lib; I investigated it and it turned out that the > *.o files have the same modification time (in seconds) as the target > lib.a (which was produced/updated in the last directory worked on) and > gmake thinks that the lib.a is uptodate. > > Any idea how to address this in the Makefiles? > > Well I could place (and it works) a 'sleep 1' into the loop, but I think > that there is some better way. Could this be a solutionn for you: $ sysctl -d vfs.timestamp_precision vfs.timestamp_precision: File timestamp precision (0: seconds, 1: sec + ns accurate to 1/HZ, 2: sec + ns truncated to ms, 3+: sec + ns (max. precision)) Beware: This is a global variable, higher resolution timestamps are not supported on all filesystems, and not all programs check for the sub-second part of the timestamp value ... Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?543BCC97.7080608>