RFC: Add a batch file to compile mc with MSYS2 instead on GnuWin32

[proski]

GnuWin32 is not actively developed. It doesn't even provide a recent gmake compatible with our makefiles.

MSYS2, other the other hand, is actively developed. It is also included with Git for Windows.

Only OpenWatcom and Strawberry Perl are supported at this time. Perl included with MSYS2 is not supported.

[proski]

This PR is mostly to help others build MC for Windows. I'm not sure if it needs to be merged, although it should not cause any harm.

This script works around numerous issues that need to be addressed elsewhere in the code. I made sure to add comments to the script. Following is an extended version.

It's time to migrate from GnuWin32. It's too old. The latest file on Sourceforge is over 12 years old: https://sourceforge.net/projects/gnuwin32/files/

The link to GnuWin32 in the mcwin32 documentation (https://unxutils.sourceforge.net/) has a broken link to https://unxutils.sourceforge.net/UnxUtils.zip - not reassuring.

The version of GNU make in GnuWin32 doesn't support the else-if directive used in the mcwin32 makefiles. A newer GNU make is provided under support but not mentioned in the documentation.

MSYS2 is a better alternative. It is also part of Git for Windows. Unfortunately, it has a problematic sh.exe executable, but #40 and #41 should deal with it.

Ideally, we should be using the version of Perl that comes with MSYS2, but it's not working due to its path conversions. It can be supported in the future. ActiveState Perl is too greedy and annoying, which leaves Strawberry Perl as the best option at this time.

It's a bad idea to use (and potentially package!) a random Busybox binary in PATH when one exists under version control.

Likewise, GNU Make from the version control would be used for predictable results. MSYS2 doesn't ship GNU make. There is one in Strawberry Perl, but it doesn't feel right to use it.

The MSYS2 executables need to be in PATH. Using the --binpath option for makelib.pl doesn't work, the path ends us with forward slashes in makefiles, which doesn't work unless sh.exe is already in PATH (chicken and egg problem). Also, the path is not added to gzip - should be easy to fix.

The build fails without the BUILDNUMBER file. The logic to create it appears to be faulty. I'd rather avoid having the build number unless it's set explicitly by the build system. For now, the fix it to set it to 1. Interestingly, echo 1 >BUILDNUMBER writes 1 followed by whitespace and echo 1>BUILDNUMBER writes ECHO is on. to BUILDNUMBER. What a mess - I had to use Busybox to write 1 to a file!

I added the GNU make invocation at the end, so it's not just a "config" script, it's a "config and build" script. The reason is to ensure that the correct GNU make binary is run.

[adamyg]

Understand issue with win/unix style tools, dealing with similar for years; there is never a clean solution
note github workflows don't utilizes gnuwin32, busybox for shell, msys +strawberry, see mc/.github and gmake: support/gmake-42.exe

[proski]

Good to know. I wish I looked there earlier. Still, it would be good to have scripts for users wishing to compile mc locally, with support for incremental builds and more environment variability.

[Neustradamus]

@adamyg: Any news about this PR?

[Neustradamus]

@adamyg: It will be nice to merge?

[adamyg]

Unsure about the host specific abs paths, yet wont deny there are similar within some other support scripts.
For example, example script wont function on local system as neither msys nor strawberry use the same installation locations. Note: Ive similar scripts with greater local host knowledge living within the same directory yet wont publish for same reasons.

Slowly cleaning up scripts, removing installation assumptions and documenting build methods/requirements via an INSTALL doc using CI integrations as working examples. https://github.com/adamyg/mcwin32/blob/master/.github/workflows/build.yml.

Could add as an example.