> Date: Wed, 15 May 2013 07:44:25 -0700 > From: David Boyce <david.s.bo...@gmail.com> > Cc: Eli Zaretskii <e...@gnu.org>, bug-make <bug-make@gnu.org> > > Given that this is a Windows-specific problem, couldn't the fallback > be that make switches over to native calls (FindXXXFile or > QueryDirectory or whatever) to read the problem directory?
This won't help, unless we call the "wide" (a.k.a. "Unicode") variants of the APIs, which means a lot more trouble than this obscure problem is worth, because of the need to convert the file names from UTF-16 to something the rest of the code can grok. IOW, readir fails because FindFirstFile/FindNextFile fail, when their "ANSI" variants are invoked. To fix that, you need to call the Unicode variants. > Or even fork a shell and run "dir"? This won't work at all, because cmd.exe can only use the console codepage, and thus will again fail for the files in question. In any case, there's no reason to use any of this just to check whether a file by a specific name exists in a directory. The current code piggy-backs Make infrastructure, but that is not needed for the issue at point. A Windows specific fix will therefore simply not use dir_contents_file_exists_p. I asked the general question whether we want to barf in this case, because it is not clear to me other platforms should, either. If the decision is that this should be fixed in Windows specific code, there are easier ways than what you suggest. Thanks. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
