Re: Gmake UTF-8 Support?

[Kaz Kylheku (gmake)]

On 2021-09-29 10:48, Eli Zaretskii wrote:
> > Date: Wed, 29 Sep 2021 10:06:22 -0700
> > From: "Kaz Kylheku (gmake)" <729-670-0061@kylheku.com>
> > Cc: nobozo@gmail.com, help-make@gnu.org
> >
> > > I think the underlying OS also must support UTF-8 encoded file names
> > > (or be agnostic to file-name encodings).  So, for example, on
> > > MS-Windows using UTF-8 in Makefiles will not work if it is used for
> > > file names.
> >
> > Test using Cygwin:
>
> Cygwin is not MS-Windows, it provides a rich layer of Posix
> functionality, including UTF-8 support, above Windows. Try the native
> Windows build of GNU Make instead.

Which build is this?

> > When I open the dire^H^H^H^Hfolder in Windows Explorer,
> > the 対象 name correctly appears, too. Thus, native Windows understands
> > the name properly.
>
> Because Cygwin converts UTF-8 into UTF-18, the so-called "Unicode
> encoding" that is native to MS-Windows.  It's an illusion.

Well, yes; it's the run-time library doing the right thing with
UTF-8 in path names in file-related functions.

Every program on Windows must bring its own run-time library;
Windows doesn't provide one. Different libraries have different
capabilities. For instance, programs compiled with Microsoft tools carry
the MSVC redistributable run-time DLL (or else have it statically 
linked).

However, a port of GNU Make using that particular run-time would be
GPL-violating, so we may safely regard that as not existing.

In any case, Cygwin is possible solution for users who want to use
GNU Make as a build tool on Windows, and need UTF-8 in paths.