NFS dir timestamp question

In my code compilation environment, I have setup my Makefile
dependencies to use a directory timestamp, like this:

abc: my_obj_dir
$(CC) my_obj_dir/*.o $(LDFLAGS) -o abc

my_obj_dir contains a bunch of .o files. This method assumes that
whenever any file in my_obj_dir changes, the timestamp of my_obj_dir
changes too. So when any .o file gets updated, program "abc" will be
regenerated using those files. This provides an easy way to keep abc
up-to-date, even when the number of .o files in my_obj_dir changes.

This method works fine on locally mounted partitions, but it fails when
my_obj_dir is mounted over NFS. I found that when a new file gets
created in my_obj_dir, my_obj_dir's timestamp is updated, which is
expected. However, when an existing file gets changed/overwritten,
my_obj_dir's timestamp is NOT changed. Hence, abc is not regenerated.

This doesn't seem to be an NFS caching problem, because the timestamp
of my_obj_dir on the NFS server really did not change.

Is this an expected behavior with NFS? If so, what would be a better
solution to achieve the same dependency checking behavior as I
described above?

Thanks.

> Is this an expected behavior with NFS?
Modifying a file doesn't change the directory it contains. But that's
not the question you need to ask. The "right" question is, what is gcc
doing? Try this:
echo 'int main() { return 0; }' > foo.c
gcc -c foo.c
strace -f gcc -c foo.c 2>&1 | grep foo
to see what gcc (and as) are up to. In my case, I see (among other things):

[pid 17180] unlink("foo.o")

This happens on my machine whether the directory is NFS mounted or not.
So, this says the directory is being modified. Since the timestamp on
the files is accurate only to the nearest second, it is quite likely
that the directory and the .o file will wind up with the same time
stamp. Whatever make does with this, it's not likely to be what you
want :-)

With a large .o file and the higher latency of NFS, the .o file is more
likely to wind up appearing newer than the directory.

> If so, what would be a better
> solution to achieve the same dependency checking behavior as I
> described above?

Make the dependency on the .o files explicit. The "info" files that
come with make have an example that shows you how to manufacture a list
of .o files from a list of source files.

Thanks, your analysis helped me understand what's happening better.

I was trying to set it up so that an explicit list of .o files isn't
necessary. I guess I need to rethink the approach.