> From: Costas Argyris <costas.argy...@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.