Re: Gmake UTF-8 Support?

[Eli Zaretskii]

> Date: Wed, 29 Sep 2021 11:15:40 -0700
> From: "Kaz Kylheku (gmake)" <729-670-0061@kylheku.com>
> Cc: nobozo@gmail.com, help-make@gnu.org
> 
> > 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?

The one produced by build_w32.bat.

> > 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.

Yes, but which run-time library?  Cygwin adds a special, very large,
run-time library on top of the C runtime that comes with Windows.

> Every program on Windows must bring its own run-time library;
> Windows doesn't provide one.

That's incorrect.  Windows does provide a stock runtime library, it's
called MSVCRT.DLL.

> 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).

The redistributables only add newer functions above the default, so
that your program could run on older versions of Windows and still use
functions added in later versions.

But no MSVC redistributable adds support for UTF-8 encoded file
names.  So this is a tangent, unrelated to the issue at hand.

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

Which is why ports of GNU software to native MS-Windows, in particular
those using the MinGW development environment, link only against
MSVCRT.DLL, which is part of the OS and thus does not cause violation
of the GPL.

> 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.

It is a solution for those who can use Cygwin as their development
environment, and don't need to run native Windows tools from their
Makefiles.

In any case, this is not relevant to the point I wanted to make: to be
able to use UTF-8 reliably in Makefiles you need to make sure that the
underlying libc and the OS support file names encoded in UTF-8.  Most
builds of GNU Make out there do, but not all of them.