On 6. 6. 25 17:50, Timofei Zhakov wrote:
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.
It says "fail-fast: false" in the YAML file, that might be it, or not;
MSBuild is strange about that.
Ah, so I'm blind. Yes, the OpenSSL feature tests are failing -- just as
they are in the SCons build, but for different reasons. In this case
it's probably actually a 64bit/32bit mismatch with the OpenSSL
libraries, as you say below.
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.
Well, this is how Ivan set up the Windows build for GitHub, I hadn't
even thought about about that we're actually cross-compiling here. Or
should be.
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.
We'd have to split the current single YAML into two. Also, this being
MSBuild, CMAKE_BUILD_TYPE doesn't actually mean anything to the
generator, and we could run both debug and release builds in a single
script, saving half of the time spent on fetching dependencies.
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.
It's just "pip install Ninja" and passing "-G Ninja" to cmake, more or
less. Ninja is a Python package. but we don't have Python on the
builders, that could be added, though. The "other" issue is getting it
to find the right toolchain.
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...
It probably wasn't working as well as you'd imagine, maintaining such a
cache is not trivial. However, it appears that GitHub has a solution:
https://github.com/actions/cache
#notapriority
-- Brane
