bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnu make timing problem ?


From: Paul D. Smith
Subject: Re: gnu make timing problem ?
Date: Sun, 4 Feb 2001 22:13:22 -0500

%% Eldar Firing <address@hidden> writes:

  ef> We have been using gnu make for several years in our development
  ef> environment.  (C++ code, IRIX / Linux Mandrake platforms).
  ef> Current version is 3.79.

You should try 3.79.1 (the latest) just to be sure.

  ef> As we are using faster and faster compiling machines, we have
  ef> discovered what seems to be timing problems with gnu make.

  ef> Is one second the finest resolution that gnu make uses when
  ef> checking dependencies ?

Make uses the resolution of the underlying filesystem, of course.

Make is completely stateless: it doesn't store any information about
targets on its own, it merely examines the targets as they exist when it
is invoked.  Make uses the stat(2) system call to retrieve the time last
modified for targets, and compares them against their prerequisites.

Most traditional filesystems store TLM values as time_t, which has a one
second granularity.

Some newer filesystems provide a very much higher granularity, such as
nanosecond.  If your system supports this, the "configure" script that
comes with GNU make will detect it.  You will have to examine the
config.h file configure generates and look to see if ST_MTIM_NSEC is
defined, if you're not sure.

Also, note that for libraries the problem is worse: the definition of
the archive format used by ar stores times for each .o added to the
archive in seconds.  Even on filesystems with higher resolutions,
archive members will only have second resolution.

You should get GNU make 3.79.1; it handles this a little bit better.

However, there's really nothing GNU make can do about this; it's at the
mercy of the filesystem.

There are build tools that are not stateless and use different
algorithms to determine of something is out-of-date; they keep
information from the last build and compare the current situation
against that.  It's on GNU make's TODO list to implement something like
this, but this is not something that anyone is currently working on
AFAIK.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist



reply via email to

[Prev in Thread] Current Thread [Next in Thread]