That's most probably because $(wildcard) calls a Win32 API that is
case-insensitive. So the jury is still out on this matter, and I
still believe that the below is true:
In that case, are you aware of any Make construct other than $(wildcard)
that will lead to calling an API of interest? I'd be happy to test it against
the patched UTF-8 version of Make that I have built.
In any case, do you see this as a blocking issue for the UTF-8 feature?
Is the concern that the UTF-8 feature might break existing things that
work, or that some things that we might naively expect to work with the
switch to UTF-8, won't actually work?
This is about UCRT specifically, so I wonder whether MSVCRT will
behave the same.
That's true. I wonder how the examples I did so far worked, given
that (as you found out) my UTF-8-patched Make is linked against
MSVCRT. Is it just that everything I tried so far is so simple that it
doesn't even trigger calls to sensitive functions in MSVCRT? Because
from what I found online, MSVCRT does not support UTF-8, and yet
somehow things appear to be working, at least on the surface.
Only on Windows versions that support this.
Yes, this whole feature makes sense only on
Windows Version 1903 (May 2019 Update)
or later anyway (this is Windows 10).
Previous versions will simply be unaffected. Make will still run, but
will still break when faced with UTF-8 input in any way.
Given that the feature will only work on Windows 10, UCRT will also
be available, so if linking against UCRT it will be possible to call
setlocale(LC_ALL, ".UTF8") and get full UTF-8 support in the C lib as well.
If linking against MSVCRT, we are forced to face the restrictions it has anyway.
Which brings me back to my question of whether you see this as a potential
blocking issue for Make switching to UTF-8 on Windows by embedding the
UTF-8 manifest at build time.