the build fails after switch to macos-13 on manual page generation:
```
dyld[39415]: Symbol not found: _glfwCreateWindow
Referenced from: <2CA04B35-6318-3824-91FA-664E963F3C86> /Users/runner/work/UltraGrid/UltraGrid/bin/uv
Expected in: <no uuid> unknown
Could not obtain data from UG/reflector output!
```
Please note that the corresponding error in master (from which was this
commit cherry-picked) was the following, which seems to be the same issue:
```
dyld[41003]: Symbol not found: __Z11IsRGBFormat21NTV2FrameBufferFormat
Referenced from: <2945C378-5453-3610-9AA4-63E2723BBA5D> /Users/runner/work/UltraGrid/UltraGrid/bin/uv
Expected in: <no uuid> unknown
Could not obtain data from UG/reflector output!
make: *** [uv.1] Error 3
make: *** Waiting for unfinished jobs....
```
which tries to run bin/uv with --fullhelp.
(this fails only if run within the script data/make_man.sh, not when run directly)
Workaround to current MSVC error with CUDA 11.8:
```
C:\Program Files\Microsoft Visual
Studio\2022\Community\VC\Tools\MSVC\14.41.34120\include\yvals_core.h(888):
error: static assertion failed with "error STL1002: Unexpected compiler
version, expected CUDA 12.4 or newer."
```
CUDA 11.8 is used for compatibility with CC 3.5 (Kepler) devices. The
support for those will however end in 5 days [1] so we may swich to CUDA
12.x later.
[1]: https://endoflife.date/nvidia-gpu
the message: `Error: No such keg: /opt/homebrew/Cellar/asciidoctor`
is now print on stderr, which disturbs GitHub CI (complains about it in
action summary annotations; just a warning).
`
Latest MSVS 2022 17.10.34928.147 (MSVC v14.40.33807) in GH runner
20240603.1.0) is no longer compatible with CUDA 11.8.0.52206. CUDA refuses
to compile because of unsupported compiler. Previous version 17.9.34902.65
(GH runner 20240514.3.0) was OK.
As MSVS 2022 is supported by CUDA 11.8 in general, we can pass
-allow-unsupported-compiler flag.
The GitHub actions now complain if trying to install a formula, that is
already installed, eg:
```
run macOS (macos-14)
pkg-config 0.29.2_3 is already installed and up-to-date. To reinstall 0.29.2_3, run: brew reinstall pkg-config
```
As a workaround, install just the formulas, that are not already
installed.
Building rav1e requires nasm 2.15 (if asm is not disabled) while U20
has just 2.14.02, so that the build in CI currently fails, anyways.
Pick sse4 for now but expect using avx2 version later, depending on
UG_ARCH value.
\+ populate PKG_CONFIG_PATH immediately
In CI on x86_64, for some reason, the path defaults to
/Library/Frameworks, while otherwhere to @rpath. So enforce to
/Library/Frameworks to be deterministic.
\+ build x86_64 from source as well to:
1. be consistent with the arm64 build
2. the binary x86_64 already had hardcoded the path @loader_path/../Frameworks/
instead of @rpath, which would require yet another handling
Use the installer and rely on dylibbundler v2 to deploy the framework
correctly.
Note: in the macOS/install_others.sh script, make sure that the env var
modification is global (== not just in the subshell) in order to be updated
by subsequent commands in the same script.
disabled in 3a076d24
The VideoMasterHD[_audio] did have invalid signature because of tweaked
internal paths, which caused Apple runtime to kill the process. Removing
the signature is not sufficient (the runtime requires signature) so we
sign it by our key.
Remove absolute path from library location - we are in the directory
anyways.
This will be useful for local use (to copy and paste) when the library
is already copied to `$(xcrun --show-sdk-path)..` etc.
\+ early return
It is not needed to split the string like this:
```
a="potentially long string on"\
"multiple lines"
```
but it is better rather to put the '\' inside the string:
```
a="potentially long string on\
multiple lines"
```
Download installers if not present. They usually are, because are cached
by the workflow. However, this change is mainly to allow the installation
not by CI but on some local computer for debugging purposes by C&P.
This fixes all occurences of `cmake --build` as it already was in one
case with commit HEAD~7.
If omitted, CMake leaves the number of processes used on underlying
implementation, which turns out to `make -j`, thus unlimited number of
cores, which is undesirable.
Using `cmake --build . --parallel` actually doesn't limit the number
of processes because it just passes the number (here none) to make,
resulting in `make -j`.
This is a possible explanations of macOS runner freezes, as eg. here:
<https://github.com/MartinPulec/UltraGrid/actions/runs/7641831068>
(last relevant message in log is `[100%] Built target joysticks`).
