[Top][All Lists]

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

[bug #23210] target/dependants with equal mtime

From: anonymous
Subject: [bug #23210] target/dependants with equal mtime
Date: Thu, 08 May 2008 18:46:37 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1


                 Summary: target/dependants with equal mtime
                 Project: make
            Submitted by: None
            Submitted on: Thursday 05/08/2008 at 18:46 UTC
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: 3.81
        Operating System: POSIX-Based
           Fixed Release: None



Consider a set of Makefiles like the following:

- - - - dir1/Makefile - - - -
../libfoo.a: foo1.o
        ar rcs ../libfoo.a foo1.o

foo1.o: foo1.c
        cc -c foo1.c
- - - - - - - - - - - - - - - -

- - - - dir2/Makefile - - - -
../libfoo.a: foo2.o
        ar rcs ../libfoo.a foo2.o

foo2.o: foo2.c
        cc -c foo2.c
- - - - - - - - - - - - - - - -

where a "make" is executed sequentially in the
two directories.  My expectation is that foo1.o
will be built and ar'd into libfoo.a, then foo2.o
will be built and also ar'd into libfoo.a.

But what actually happens is that foo1.o is indeed
built and ar'd into libfoo.a and foo2.o is also built,
but then the date on libfoo.a is compared to the date
on foo2.o and due to the coarse granularity of the
mtime, foo2.o is observed to have the same date as
libfoo.a rather than being newer, and it is not ar'd
into libfoo.a.

Is this a bug in make, or is the above example an
illigitimate use of make?

If it is considered a bug in make, here's a simpler
more artificial example that demonstrates the same

- - - - Makefile - - - -
a: b
        touch a
        touch b
- - - - - - - - - - - - -

And here is a command which demonstrates behavior
I think is erroneous:

% rm -f b ; touch a ; make a

In this example I would expect it to see that "b"
is not there, and determine that it must make "b"
as well as update "a".  Thus I expect to see
  touch b
  touch a
But instead on a system where the fstat gives an
mtime with granularity in seconds which seems
common, the above command usually results in
  touch b
being executed.  Apparently it looks at the
dependancy list for "a", decides it needs to
make "b", does so, looks at the date on "b"
after it has made it, then decides that since
"b" is not strictly newer than "a" based on
the date with 1-second granularity it won't
update "a".


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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