[Top][All Lists]

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

Re: directory caching anomalies in win32

From: Eli Zaretskii
Subject: Re: directory caching anomalies in win32
Date: Tue, 24 Apr 2007 09:09:24 +0300

> Date: Mon, 23 Apr 2007 16:14:47 -0700 (PDT)
> From: Aaron Shatters <address@hidden>
> Cc: address@hidden
> This fragment handles the problem that inode emulation on Windows
> >filesystems are not reliable.  It replaces the inode check by
> >`stat'ing the directory whose normalized file name is stored in
> >dir->path_key.
> >
> >Does this code really get run when you invoke $wildcard, and why?
> Yes, it does.  "func_wildcard" calls "string_glob".  "string_glob" calls 
> "file_exists_p".  "file_exists_p" calls "dir_file_exists_p".  
> "dir_file_exists_p" calls "dir_contents_file_exists_p"... and there you have 
> it.  The code above gets run if the $(wildcard...) argument doesn't contain 
> any wildcard characters (for example: file.o), and the file did not exist 
> when the directory contents was cached.

Thanks for tracing this.

Paul, up until now it looks like this is a general problem with Make's
implementation of $wildcard: it doesn't hit the disk to find out
whether the directory got modified since it was read and cached.  I
think that if file.o in the above example was one of the targets of
the current Makefile, Make adds it to the cache, but what about files
that got created as side effects of rules' commands without Make's
knowledge?  Doesn't this mean $wildcard should always check whether
the directory was modified?

Or am I missing something?

reply via email to

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