I didn't verify this but the comments in the code suggest that when the open directory limit is reached all the contents of the directory are cached before the handle is released so it may be slightly less draconian to just release the handle without completing the caching and reopening it if another search is required - might be quite a bit more complex though.
Also assuming that the wildcard has been evaluated before the clean target is processed (as it must be to run in to the issue) is there a point where the variables have been expanded and the handles can be released (as they would no longer be needed) before the targets are processed - it seems odd that the handles are held until make exits. As a side note i think the only reason i need to do this sort of thing at all is due to the mtime of directories being updated when their contents change thus i get odd behaviour when building something a second time that hasn't changed (early build outputs end up with an earlier mtime than the directory they are in and depend on) - Again from the comments in the code it seems this might be specific to NTFS. However i was wondering if there was a better way to specify a dependency on a directory without using the filter-out / wildcard construct. Or even if it should be considered a bug that make checks mtimes on directories (at least under NTFS). I guess if the directory doesn't exist then make doesn't know it's a directory but then it won't be checking the mtime and if it does exist then it can tell it's a directory and who cares what the mtime is. Of course i may be completely wrong about why i have to construct directory dependencies like this or the validity of directory mtimes and their importance in other use cases. Anyway the solution i have reduces any sense of urgency for me but i think my boss would be happier if i hadn't just made our build environment dependent on a special version of make :) 2009/4/3 Eli Zaretskii <e...@gnu.org>: >> From: Peter Halliday <invalid.nore...@gnu.org> >> Date: Fri, 03 Apr 2009 13:28:36 +0000 >> Cc: >> >> I think I have a fix for this issue (at least it's working for me with my >> makefiles). I have edited dir.c to limit the maximum number of open >> directories under windows to just 1 (normally it is 10) this results in >> directories being closed straight away after caching contents. > > Thanks, but I hope there is a less Draconian solution to this bug. I > will have a look when I have time. > _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make