UnigramDev/Unigram/develop • 1e841d6 • 7 files, +658/-308
Get the VLC build working again, and generate the plugin cache

The build failed while fetching contribs, so nothing downstream had been
exercised in a while. Fixing that surfaced several more problems.

The submodule fix is carried as 0005: $(SF) pointed at a SourceForge mirror
that no longer resolves, and the libvlc-only build tried to package an NSIS
installer around a vlc.exe that -z never builds.

build.ps1:

- dropped -it from docker run. It requires a terminal on stdin, so the script
could not run from CI or any non-interactive shell.
- check the exit code. Previously a failed build fell straight through to
packing, turning a broken build into a stale package rather than an error.
- pass -D as a separate argument. getopts captured the '=' from -D=<path> into
OPTARG, which reached -fdebug-prefix-map and put a literal '=' in front of
every source path recorded in the PDBs. Crash reports showed frames as
"=C:\...\win64-uwp\modules\=C:\...\modules\audio_output\wasapi.c", and they
now resolve normally.

The plugin cache was never generated: Makefile.am only runs vlc-cache-gen when
build == host, so cross-compiling always skipped it, and the committed
plugins.dat was left over from 3.0.22-rc1. cache.c compares the version with
memcmp, so it was being rejected outright and every launch rescanned all the
plugins.

plugins-cache.ps1 generates it. The UWP build loads plugins with
LoadPackagedLibrary, which only resolves inside the calling process's package,
so cache-gen finds nothing when run from a plain directory. It therefore stages
the plugins the nuspec ships, registers that as a loose package, and runs
cache-gen inside it.

ARM64 cannot execute on an x64 host, so its cache is derived rather than
generated. bank.c validates each entry by mtime and size only, and the module
descriptors are architecture-independent, so the x64 cache is re-stamped with
the ARM64 files' metadata. Verified independently: all 36 entries carry the
right mtime and size for their architecture, and 31 of them genuinely differ
between the two.

That also means one plugins.dat cannot serve both architectures, so the nuspec
now ships one per architecture instead of the same file twice.

The nuspec referred to the install directory as vlc-3.0.23-2 in 284 places
while the build produces vlc-3.0.23, so packing could never succeed. The
version is now substituted via -Properties. A wildcard was simpler but NuGet
then treats each target as a directory and produces
build/win10-x64/libvlc.dll/libvlc.dll.

Verified end to end: both architectures build, the caches are generated and
checked, and nuget pack produces a package with 36 plugins and a distinct
cache per architecture.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • 07ab82d • 2 files, +0/-0
Latest tlottie fixes

UnigramDev/Unigram/develop • 942b8a3 • 3 files, +15/-8
Update libvlc

UnigramDev/Unigram/develop • 0525c26 • 3 files, +4/-33
Display voice notes in rich messages properly

UnigramDev/Unigram/develop • 3418495 • 1 files, +20/-33
Fix instant view styles

#unigram