Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI: split "Windows workflow" into two: MSYS64 and VisualStudio #103

Open
GitMensch opened this issue Jun 27, 2023 · 2 comments
Open

CI: split "Windows workflow" into two: MSYS64 and VisualStudio #103

GitMensch opened this issue Jun 27, 2023 · 2 comments

Comments

@GitMensch
Copy link
Collaborator

The first will just be renamed, the second will get its dependencies with vcpkg (there's likely a pre-configured action for that, which caches its results), then compile (both win32 and x64) and run the testsuite with the current autofonce binaries.

@lefessan
Copy link
Member

lefessan commented Jul 2, 2023

To be honest, though we generate Windows binaries by cross-compilation, we haven't tried them yet... We will probably find bugs, typically related to how shells/which shells are started to run the testsuite. I haven't checked how the testsuite is currently ran under Windows on the current CI, which Unix env is being used for that and so on...

@GitMensch
Copy link
Collaborator Author

To execute those with a cross-compile environment the normal handling with atlocal is used (the CI worker has to have Wine installed) - but the current GC environment is already MSYS64, as far as I remember. Testing those is therefore done by the normal make check.

To build and test VC generated binaries "manually" with the testsuite the following procedure is currently used:

  • get all dependencies with vcpkg
  • manually adjust the provided build_windows/config.h.in (set used libraries via sed to create config.h)
  • create tarstamp.h with the provided PS script
  • use msbuild to generate the binaries
  • use the provided "makedist" to create the binary package including the "extras"
  • [possibly upload the binaries as artifact]

This is the setup part (it seems reasonable to replace sed by powershell, but no one has done that so far):

echo setup local configuration

sed "build_windows\config.h.in" -e's/\(#define CONFIGURED_ISAM *\) [A-Z]*/\1 BDB/g' -e's/\(#define CONFIGURED_CURSES *\) [A-Z]*/\1 PDCURSES/g' -e's/\(#define CONFIGURED_XML *\) [A-Z]*/\1 XML2/g' -e's/\(#define CONFIGURED_JSON *\) [A-Z]*/\1 CJSON_CJSON/g' >  "config.h"

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

then, for the actual test:

  • execute the matching set_env.cmd (this will setup all the paths)
  • from this open a msys or cygwin shell and run the testsuite from there, using the spacial atlocal_win (just copy)

Using autofonce could replace the last part, dropping the need for a POSIX shell environment (still either autofonce would have to either replace some of the tools or need sed/grep/diff/tr binaries in its PATH).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants