On Sun, 2023-03-19 at 13:42 +0000, Costas Argyris wrote: > 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.
There is no one "standard way". The GNU project doesn't provide binaries on any platform, including Windows: we only provide source code. So whatever methods people use to build the software is the "standard way" for them. I don't do Windows: my system did not come with Windows and I don't own a Windows license, so when I test before releasing these days I use the free developer Windows VM provided by Microsoft. It expires regularly so I don't spend time customizing it. Because of that I personally use MSVC (the latest version, which comes pre-installed on the VM) and the build_w32.bat file, and I have Git for Windows POSIX tools on my PATH. I install Strawberry Perl to be able to run the regression tests, and that's it. This is only intended to be a trivial, anti-brown-paper-bag test for coding errors or obvious regressions. Other people (like Eli who is the primary maintainer of GNU Make for Windows) have other environments and do more vigorous testing. But I don't believe Eli uses autotools on Windows, either. > 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? You will have to ask each of them. They all do their own thing and we must be doing an OK job of keeping things portable, since they rarely come back to us with requests of any kind so we don't really know what they are doing. > 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? Patches can be provided in any order, but until build_w32.bat is updated there won't be any testing of these features during the "normal" development process. Presumably (but again, you'll have to ask them) the MinGW folks etc. will take release candidate builds and verify them in their own environments, once those become available. This is not to discourage you in any way: UTF-8 is assumed by GNU Make on POSIX systems and getting that to be true on Windows is a big step in the right direction IMO!