> 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: martind@swiftboat:~/download/make-git$ git rev-list --all -- dir.c | xargs git grep 'sizeof.*dirfile))' | cut -f1 -d: | uniq --count | grep -v -w 2 martind@swiftboat:~/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:psm...@gnu.org] Sent: Friday, October 07, 2016 05:07 To: Martin Dorey; Kyle Rose; bug-make@gnu.org 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. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
