> > > Regarding the current state of GitHub actions: > > > > * Windows x86 (32-bit) CMake builds are failing and I have absolutely > > no idea why. The last output is during the build, says "Generating > > code...", then exits. No diagnostics, nothing. > > > @Timofei, any ideas? > > I think I have figured this out.
First, maybe you didn't notice that, but it fails when buckets\ssl_buckets.c is being built (scroll up the logs a little bit). By the way, I don't know why it doesn't inta-fail the build. So, this workflow is using Visual Studio generate (generate vcxproj files), meaning it determines compiler and environment on its own like an average Visual Studio project. On the other hand, Ninja is just a set of rules, so cmake will need to find a compiler and pass it to the build files on its own. But the thing is in the workflow, there is nothing can tell cmake to switch the platform to x86 (cmake defaults the Visual Studio generator to x64 platform). Meaning that x64 compiler tries to link it against x86 libraries. The simplest way to fix the problem is to pass this extra argument: `-DCMAKE_GENERATOR_PLATFORM=Win32` to cmake, so it could use the proper platform. However, unrelatedly to the original problem, it's much better to use the Ninja generator in build scripts, since it's faster, more reliable, simpler, and more customisable in terms of platforms and architectures. It could be complicated to set up, but I've done it for Subversion, so I can do it for Serf as well. I also noted that it seems to download and build OpenSSL from source, > taking quite a bit of time. Is it possible to install a binary version from > vcpkg? > > It seems like they deprecated github actions binary caching: [[[ %VCPKG_BINARY_SOURCES%: warning: The 'x-gha' binary caching backend has been removed. Consider using a NuGet-based binary caching provider instead, see extended documentation at https://learn.microsoft.com/vcpkg/users/binarycaching?WT.mc_id=vcpkg_inproduct_cli. on expression: clear;x-gha,readwrite ]]] I have no clue what to do then. And why have they even done that, since it was working well... -- Timofei Zhakov
