RE: Simpler example of pathological behavior of directory caching

[Martin Dorey]

> when a target is built, that target is explicitly added to the cache by GNU 
> make

Like I thought when I started.  Well, file.c does plausibly put it in the 
"files" hash table, but there is no communication to dir.c to update the 
"directories_contents" hash.  I think I can show that there never has been any 
such communication.  There's only ever been two calls to xmalloc(sizeof(struct 
dirfile)), in the readdir loop and in file_impossible:

address@hidden:~/download/make-git$ git rev-list --all -- dir.c | xargs git 
grep 'sizeof.*dirfile))' | cut -f1 -d: | uniq --count | grep -v -w 2
address@hidden:~/download/make-git$

So, until every system I use has the as yet hypothetical fix, I shouldn't use 
$(wildcard) after I've started changing the file system.  I don't think I've 
used $(wildcard) like that often, perhaps explaining why this has gone forever 
without being tracked down before, but I can think of one place.
 
-----Original Message-----
From: Paul Smith [mailto:address@hidden 
Sent: Friday, October 07, 2016 05:07
To: Martin Dorey; Kyle Rose; address@hidden
Subject: Re: Simpler example of pathological behavior of directory caching

On Fri, 2016-10-07 at 00:10 +0000, Martin Dorey wrote:
> ... then I failed to find any source that invalidates that cache, be
> it the whole cache, just one directory or one entry in that directory.

I'd have to reread that code to be sure but I don't think that's how it
works.  I think that what's supposed to happen is that when a target is
built, that target is explicitly added to the cache by GNU make, not
that the cache is invalidated and reread from scratch.