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!

Reply via email to