ci: consider additional windows-run with Visual Studio

[GitMensch]

the GH Actions environment windows-2019 comes with Virtual Studio 2019 and vcpkg

A setup similar to this is actually running on Appveyor currently (and btw compiled latest GCOS adjustments, too); it may be useful to test complilation (and maybe running) with at least one non-gcc build (macos is likely clang, even if named gcc, but even then much more "like gcc")

That's the CI definition that would work in appveyor, giving an overview about steps to possibly add some day:

version: 3.2-dev.{build}-vs

image:
- Visual Studio 2019

configuration:
- Release
- Debug

platform:
- x86
- x64

clone_folder: C:\projects\gnucobol_vs

environment:
  WINFLEXBISON_VERSION: 2.5.24
  WINFLEXBISON_ARCHIVE: win_flex_bison-%WINFLEXBISON_VERSION%.zip
  DEP_ARCHIVE: dependencies-%PLATFORM%.7z
  VCPKGS: zlib:%PLATFORM%-windows liblzma:%PLATFORM%-windows mpir:%PLATFORM%-windows pdcurses:%PLATFORM%-windows berkeleydb:%PLATFORM%-windows libxml2:%PLATFORM%-windows cjson:%PLATFORM%-windows json-c:%PLATFORM%-windows

install:

- cmd: >-
    set "OLDDIR=%CD%"
    echo Use vcpkg for pre-prerequisites &&   pushd c:\tools\vcpkg &&     git pull &&   .\bootstrap-vcpkg.bat &&   vcpkg integrate install &&   vcpkg install %VCPKGS% &&  vcpkg update &&  vcpkg upgrade %VCPKGS% --no-dry-run
    pushd %OLDDIR%

    echo Get flex/bison, include them in PATH
    if not exist "%WINFLEXBISON_ARCHIVE%" appveyor DownloadFile "https://github.com/lexxmark/winflexbison/releases/download/v%WINFLEXBISON_VERSION%/%WINFLEXBISON_ARCHIVE%"
    7z.exe x -y -owin_flex_bison\ "%WINFLEXBISON_ARCHIVE%" > nul
    set PATH=%CD%\win_flex_bison;%PATH%

cache:

- '%WINFLEXBISON_ARCHIVE%'

- c:\tools\vcpkg\installed\

- c:\tools\vcpkg\packages\

build_script:

- cmd: >-

    echo setup local configuration
    sed "build_windows\config.h.in" -e's/\(#define CONFIGURED_ISAM *\) /\1 BDB/g' -e's/\(#define CONFIGURED_CURSES *\) /\1 PDCURSES/g' -e's/\(#define CONFIGURED_XML *\) /\1 XML2/g' -e's/\(#define CONFIGURED_JSON *\) /\1 CJSON_CJSON/g' >  "config.h"

    powershell -ExecutionPolicy ByPass -File build_windows\maketarstamp.ps1 > tarstamp.h

    echo doing the actual build - bison + flex
    call build_windows\makebisonflex.cmd || appveyor AddMessage "bisonflex returned with %errorlevel%" -Category Warning

    echo doing the actual build - GnuCOBOL
    msbuild "C:\projects\gnucobol_vs\build_windows\2019\GnuCOBOL.sln" /m /verbosity:minimal /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"

    echo exporting dependencies
    vcpkg.exe export %VCPKGS% --raw
    move C:\Tools\vcpkg\vcpkg-export-* .\vcpkg-export
    set "VCPKG_EXPORT_DIR=%CD%\vcpkg-export"

    echo create binary dist package
    call build_windows\makedist.cmd %CONFIGURATION%

    echo wrap up dependencies for separate download
    7z.exe a -r -mx=9 "%DEP_ARCHIVE%" vcpkg-export

test: off

artifacts:

- path: build_windows\GnuCOBOL*.7z
  name: Package for VS

- path: '%DEP_ARCHIVE%'
  name: Dependencies

The only testing done here is the build of the dump module, there are some test options available (non used in appveyor so far)

[GitMensch]

While there are still issues open on MSVC builds in general, the CI itself seems to be working fine in the gcos4 branch.

The parts that I'd like to see there is not about MSVC but the "win32-posix" builds:

• MSYS1:
  • run the testsuite make check (possibly ignoring failures for now) - warning, likely needs to be run with a single job; add testuite.log to the artifacts
  • run NIST make test (must pass) - warning, may needs to be run with a single job, add tests/cobol85/summary.log as artifact
  • at least if the build (and NIST) was not failing: run make distmingwdir, adding the resulting GnuCOBOL_mingw and GnuCOBOL_mingw_dbg to the artifacts
  • possibly cache cJSON
• MSYS2:
  • run NIST make test (must pass) in parallel, add tests/cobol85/summary.log as artifact
  • If it works (I really don't know): run make distmingwdir, adding the resulting GnuCOBOL_mingw and GnuCOBOL_mingw_dbg to the artifacts

@ddeclerck Can you please inspect to do those changes there and when it works get the updated definitions to the gcos-3x branch as well?