Re: [PATCH] Use UTF-8 active code page for Windows host.

[Eli Zaretskii]

> From: Costas Argyris <costas.argyris@gmail.com>
> Date: Sun, 19 Mar 2023 13:42:52 +0000
> Cc: bug-make@gnu.org
> 
> Does this support require Make to be linked against the UCRT
> run-time library, or does it also work with the older MSVCRT?
> 
> I haven't found anything explicitly mentioned about this in the official
> doc:
> 
> https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

OK, but how is the make.exe you produced built? is it using UCRT or
MSVCRT when it runs?  You can check that by examining the dependencies
of the .exe file with, e.g., the Dependency Walker program
(https://www.dependencywalker.com/) or similar.  Or just use objdump
from GNU Binutils:

  objdump -p make.exe | fgrep "DLL Name:"

and see if this shows MSVCRT.DLL or the UCRT one.

> Does using UTF-8 as the active page in Make mean that locale-dependent
> C library functions will behave as expected?
> 
> I think so.    Here is the relevant doc I found:
> 
> https://learn.microsoft.com/en-us/cpp/text/locales-and-code-pages?view=msvc-170

This is not enough.  If locale-dependent C library function still
support only the characters expressible with the ANSI codepage, then a
program using the UTF-8 active codepage will be unable to process the
non-ASCII characters outside of the ANSI codepage correctly.  For
example, downcasing such characters or comparing them in
case-insensitive manner will not work.  This is because for this to
work those functions need to have access to tables of character
properties for the entire Unicode range, not just for the current
locale.  If you try using in a Makefile file names with non-ASCII
characters outside of the current ANSI codepage, does Make succeed to
recognize files mentioned in the Makefile whose letter-case is
different from what is seen in the file system?

> Also, since the above experiments seem to suggest that we are not
> dropping existing support for non-ASCII characters in programs
> called by Make, it seems like a clear step forwards in terms of
> Unicode support on Windows.

I agree.

> I cross-compiled Make for Windows using gcc (mingw-w64) and the
> autoconf + automake + configure + make approach, so it clearly worked
> for me, but I didn't imagine that this wasn't the standard way to build for
> Windows host.

Make is a basic utility used to built others, so we don't require a
full suite of build tools for building Make itself.

> Does this mean that all builds of Make found in the various build
> distributions of the GNU toolchain for Windows (like
> mingw32-make.exe in the examples above) were necessarily built using
> build_w32.bat?

I don't know.  I can tell you that the precompiled binaries I make
available here:

  https://sourceforge.net/projects/ezwinports/files/

are produced by running that batch file.

> Since build_w32.bat is a Windows-specific batch file, does this rule out
> cross-compilation as a canonical way to build Make for Windows?

No, it doesn't rule that out.  But using cross-compilation is not very
important these days, since one can have a fully functional MinGW
build environment quite easily.

> Assuming all questions are answered first, would it be OK to work on the
> build_w32.bat changes in a second separate patch, and keep the first one
> focused only on the Unix-like build process?

Yes.  But my point is that without also changing build_w32.bat the
change is incomplete.