Add/update Windows workflows

[ddeclerck]

This PR adds an MSVC workflow to compile GnuCOBOL and run the testsuite.

Note 1: we manually generate the tests/atconfig and tests/package.m4 files to avoid having to generate and call ./configure

Note 2: about 80 tests fail (I get the same results locally on an actual Windows machine)

[GitMensch]

yes, I've pushed because I've seen the test still hang, and then found that the sed used operates on the wrong file - as it currently does again.

[ddeclerck]

yes, I've pushed because I've seen the test still hang, and then found that the sed used operates on the wrong file - as it currently does again.

Ah, you pushed to my own branch, that's why. I assume people never do that, and I happily force-push to my branch to keep a single commit.

[GitMensch]

No problem, but as noted you need:

- sed -i '/AT_SETUP(\[MOVE to edited item (4)\])/a AT_SKIP_IF(\[true\])' testsuite.src/run_functions.at
+ sed -i '/AT_SETUP(\[MOVE to edited item (4)\])/a AT_SKIP_IF(\[true\])' testsuite.src/run_fundamental.at

[ddeclerck]

No problem, but as noted you need:

- sed -i '/AT_SETUP(\[MOVE to edited item (4)\])/a AT_SKIP_IF(\[true\])' testsuite.src/run_functions.at
+ sed -i '/AT_SETUP(\[MOVE to edited item (4)\])/a AT_SKIP_IF(\[true\])' testsuite.src/run_fundamental.at

Yup, I noticed that.

Of course, on the long term, those will be investigated locally.

[GitMensch]

Of course, on the long term, those will be investigated locally.

Sounds good. That may have been faster (but that's hard to know up front) - the CI now hangs at test 577 / 1304.

[ddeclerck]

So, here we are. The hangs are caused by popup windows that display errors detected by the runtime checker - of course in a CI environment without a GUI you can't see them. Most of those errors are of the kind shown in this screenshot: So we basically have to be very pedantic about casts with data loss and explicitly express which bits we drop. I hate MSVC so much.

[GitMensch]

https://learn.microsoft.com/en-us/windows/win32/debug/error-mode says:

Best practice is that all applications call the process-wide SetErrorMode function with a parameter of SEM_FAILCRITICALERRORS at startup. This is to prevent error mode dialogs from hanging the application.

So, in both CI cases and when running as a service, we'd like to crash the application instead of opening a popup.

During debugging on a GnuCOBOL developer environment the messages as is, including the "retry to debug", is useful.

What are your thoughts about that? Adding a call on MSVC to the startup code in libcob (also executed from cobc) to disable that popup in all cases but a special environment variable is set?

[GitMensch]

Of course that's a runtime check which is useful (and therefore explicit enabled for the debug compile) and similar things also happen with sanitizers in gcc + clang.

As you have the setup: can you check those occurrences and use bitmask for explicit loss of data?

[ddeclerck]

https://learn.microsoft.com/en-us/windows/win32/debug/error-mode says: What are your thoughts about that? Adding a call on MSVC to the startup code in libcob (also executed from cobc) to disable that popup in all cases but a special environment variable is set?

That sounds reasonable. We could use the CI environment variable, which should be defined by most CI frameworks (at least it is on GitHub, and I believe also on Appveyor ?)

[ddeclerck]

As you have the setup: can you check those occurrences and use bitmask for explicit loss of data?

I really have to go back to the GC3/4 merge.

I spent yesterday's afternoon giving @engboris all the info about this MSVC CI and prepared for him a script that reproduces the CI steps locally, so he should be able to take over this matter.

I'd go as far as suggesting to merge this PR in its current state (as it is already very helpful for its purpose), and open a new one dedicated to the fixes.

[GitMensch]

I'd say %CI% is a possible option if we leave it otherwise on; I'm looking forward for @engboris to implement this and start checking the data-loss, bitmasking where expected, which should go into two separate PRs.

Thanks for improving the CI so far. The only thing that seems to be missing and would be nice if you could add it is the binary artifacts for MSVC, created after build by executing build_windows\makedist.cmd and upload that, maybe you can inspect that before getting back to the merge, or Boris can handle this as a first PR.

[ddeclerck]

The only thing that seems to be missing and would be nice if you could add it is the binary artifacts for MSVC, created after build by executing build_windows\makedist.cmd and upload that, maybe you can inspect that before getting back to the merge, or Boris can handle this as a first PR.

Oh I couldn't get this to work ; here's what I get (using the commented bits at the end of windows-msvc.yml):

Setup using created GnuCOBOL distribution -x64-...
Setup Visual Studio (x64/amd64)...

cl.exe already in PATH
no further initialization is done for the C compiler

cl.exe now in PATH:
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\bin\Hostx64\x64\cl.exe
Compilateur d'optimisation Microsoft (R) C/C++ version 19.40.33812 pour x64
Copyright (C) Microsoft Corporation. Tous droits réservés.

cl : Ligne de commande error D8003 : nom de fichier de la source absent

Setting environment for GnuCOBOL.
Building extras with

cobc had unexpected return value -1073741515, running verbose again...
C:\Users\David\Programmes\msys64\home\David\gc4-msys1\gc3-msvc\build_windows\distnew\bin_x64\cobc.exe
Abort!