Upstream patch from Cygwin package repo

[bjosv]

Repology showed that there already is a Cygwin package, which required a patch to build.

Add the corrections from the patch:

• fix the valkey_tls linkage on Cygwin to avoid an build error when building with TLS.
• Set the SOVERSION needed for Cygwin builds.
  The built library will be named "cygvalkey-0.1.dll" instead of "cygvalkey.dll".

Additionally, build Cygwin using CMake in its own job.
Build Cygwin using CMake only, which is the supported alternative on Windows.

NOTE:
The addition of SOVERSION will also set the compatibility version field in macOS:

BEFORE:
# otool -L libvalkey.dylib
    libvalkey.dylib:
            @rpath/libvalkey.0.1.dylib (compatibility version 0.0.0, current version 0.1.0)

AFTER:
# otool -L libvalkey.dylib
    libvalkey.dylib:
            @rpath/libvalkey.0.1.dylib (compatibility version 0.1.0, current version 0.1.0)

But this seems ok, and not used in later macos release: https://github.com/giordano/macos-compatibility-version

[bjosv]

@michael-grunder maybe you know more about the compatibility version i Mac-libs (Mach-O)?

[bjosv]

/cc @fd00 Does this change seem ok? Nothing more needed?

[michael-grunder]

maybe you know more about the compatibility version i Mac-libs (Mach-O)

I don't know very much about them but I think the change is correct. AFAIK the first triplet is "compatibility version" and the second "current version". You bump the current version each release but only bump compatibility version if there is a breaking change.

Applications embed this compatibility version at link time and then check it each time the application starts. If it detects a compatibility version that is greater than the one embedded in the binary it will refuse to start.

[fd00]

Thank you for the notification.

We have only confirmed that we can build on cygwin by applying this patch.

Some of the ctest results I have run locally have not confirmed success.
(That's why we are assuming it is WIP.)

As for soversion, the cmake variable name contained SONAME, so we applied it as is.

[bjosv]

Some of the ctest results I have run locally have not confirmed success. (That's why we are assuming it is WIP.)

I added a step to run some tests on Cygwin as well, but it uses memurai which is valkey/redis windows alternative.
I haven't seen that Cygwin provides a pre-built packages for redis/valkey to be able to run ctest, but this was the easiest option.
I found and fixed one failing test which might be what you have seen.

[michael-grunder]

but it uses memurai

I switched to memurai for hiredis Windows tests a few years ago. Hasn't caused any issues that I'm aware of.

[bjosv]

I switched to memurai for hiredis Windows tests a few years ago. Hasn't caused any issues that I'm aware of.

Yes, it works fine. It was mentioned that ctest doesn't work and this is because CMake creates a test target that uses ctest, which in turn runs our test.sh that doesn't work on Cygwin with memurai.
Running the test-binary independently towards the already running memurai instance will work fine for now I hope.