Bill-Gray
Add: cross-build test for windows using LLVM-MinGW in Ubuntu.
Why using LLVM-mingw instead of plain mingw?
Short Answer: it is the only way so far to support cross-compilation for Windows on Arm. Long answer: Raw MinGW OS packages don't support cross-compilation for Windows UCRT lib. So the only way to support Windows on Arm, and compile against UCRT library and UWP framework is by using LLVM/clang/LD.LLD/MinGW toolchain. As you can see, it has everything in a small deliverable. On top of that the code generated is way smaller and faster than the old MinGW packages using the legacy MSVCRT. llvm-MinGW can also use the old MSVCRT and generate code for armv7 (32 bits) on Windows. However, Microsoft has not adopted it as a standard.
BTW, why using appveyor??? Github actions can do the same in the same environment way faster than appveyor. You can even generate new versions and automate CI/CD, generate artifacts, pre-releases, and releases.
Artifacts are now available for download. The first run is available here: https://github.com/okibcn/PDCursesMod.fork/actions/runs/4522282410#artifacts
BTW, why using appveyor???
Because "back then" there was no GitHub actions available :-)
Github actions can do the same in the same environment way faster than appveyor.
Note sure on that, the OpenWatcom builds take much less than 1 minute, same for VS arm64. But they all run single or dual-core, while the Actions (currently) have 20 parallel jobs.
@okibcn Would you be willing to "move" the Windows builds (at least the VS ones) into the GitHub actions? Should we pull this PR in now (and possibly do the Windows parts in a later PR) or wait?
BTW, why using appveyor???
Aside from the lack of GitHub Actions at the time... I don't think there is a way to do (for example) the OpenWATCOM 1.9 and 2.0 compilations on GitHub Actions. I'm open to correction on that, though.
While AppVeyor is really slow, it's been sufficient for our needs most of the time. But it'll be nice to be able to make good use of GHA and AppVeyor. I don't think it'll be an either/or choice.
Very minor nitpick : in Simon's listing of the three character set options (wide, UTF-8 forced, eight-bit), that last involves "no options set". You can explicitly set WIDE=N, but don't have to.
