Written 2026-08-14. Resume point for the work that moved the unmanaged dependencies onto vcpkg manifest mode and turned libvlc and webrtc into prebuilt downloads.
vcpkg is pinned to c3867e714dd3a51c272826eea77267876517ed99 (tag 2026.03.18) in
vcpkg.json. That commit is deliberate: it is the newest release tag that still carries zlib
1.3.1. From 2026.04.27 the zlib port renames its output to z.dll, which would break the
tdjson export filter silently and the csproj copy loudly.
Setup is now: a full vcpkg clone, either beside the repository or the copy that ships with
Visual Studio's vcpkg component. No VCPKG_ROOT needed, no vcpkg integrate install, no port
edited by hand. Directory.Build.props finds it, Directory.Build.targets checks it is not
older than the pin and prints the fix if it is.
| dependency | how it arrives |
|---|---|
| ffmpeg 7.1.2 | overlay port, Libraries/vcpkg-ports/ffmpeg, carrying the --enable-* flag set |
| libvlc 3.0.23 | overlay port downloading libvlc-3.0.23-2 from UnigramDev/deps |
| webrtc m123 | overlay port downloading webrtc-2026-08-19-1 from UnigramDev/deps |
| everything else | stock ports at the pinned baseline |
UnigramDev/deps holds the build and packaging scripts, the webrtc patches, and the release
archives. libvlc/ and webrtc/ each expose build.ps1 and pack.ps1. Its README documents
publishing a new archive.
The forks: UnigramDev/vlc unigram-12.7.5 at
739b198e18, UnigramDev/webrtc-uwp m123 at
801b013618. Both are pushed and both releases name their commit. The VLC checkout that used to
be a submodule is an ordinary clone at C:\Source\vlc.
Libraries/vlc and Libraries/webrtc are gone from this repository.
- Both native projects build against the ports, and a Release x64 msixbundle packages.
- The ports install, and the libvlc archive repacks byte-identically from the relocated checkout.
- The manifest resolves at the pinned commit with the overlay taking precedence.
- tdjson builds for
arm64-uwpagainst vcpkg at the latest baseline (a separate question, asked because TDLib was considering the move). deps/webrtc/build.ps1 -SkipAcquireandpack.ps1, run 2026-08-19: all four configurations built clean under Visual Studio 18 and were published aswebrtc-2026-08-19-1. The acquire half — fetch, sync, patch — is still unexercised.- A build that downloads from the releases, 2026-08-25. Nothing was seeded: vcpkg fetched
libvlc-3.0.23-x64-uwp.zipand both webrtc x64 archives from the release URLs and verified them. Only the webrtc headers came from the cache. - A build from a fresh clone, 2026-08-25:
tdjson\build.ps1 -arch x64,ARM64followed byBuild.Modern.ps1 -Identity Original -Mode StoreUpload -Platform x64,ARM64. TDLib took 28.5 minutes for both architectures, x64 compiled and ARM64 out of the binary cache, and the bundle carried x64 and ARM64 with all thirty language packs. - The per-triplet install roots hold. The ARM64 pass handled 26
arm64-uwppackages and nox64-uwpone, and the log records no removal. Neither the app build nor a later TDLib rebuild changed a byte of either tree — vcpkg's install returned in under a millisecond both times.
- The packaging wizard. The two experimental settings in
8aebeaa71were only exercised from the command line.
- Commit and push the tgcalls changes.
UwpScreenCapturer.cppcarries the try/catch from the fork review and the libyuv include fix. The second one is load-bearing: removing the hardcoded webrtc include path is what made a plain<libyuv.h>ambiguous. Until it is on the fork the submodule pin cannot move and a fresh clone will not compile Telegram.Native.Calls. This is the only thing blocking someone else from building. - The download test above.
- Decide on the experimental settings. The control run for the double build is: revert
ShouldUnsetParentConfigurationAndPlatformin the wapproj, rebuild, and look for twoTelegram -> ...Telegram.exelines and twoGenerating native codepasses instead of one.release.binlogin the repository root is the "after" half. Libraries/tdjsonstill has no answer for the confidential prerelease drops. The design was$(TdjsonDir)pointing outside the repository, with the drops never inside the working tree.td_api.bak.tlis currently untracked and unignored.- The TDLib ABI patch to
td_json_clientexists only in the working tree of the submodule. Same class of problem as the wasapi change and the unpushed webrtc branch, both fixed today.
- vcpkg reads its version database from the checked-out working tree, not from the commit
named by
builtin-baseline. A checkout older than the pin fails with "no version database entry for<port>at<date>", which does not hint at the cause.git fetchis not enough; you must check out the pin and re-bootstrap. - Autolink is off (
VcpkgAutoLink=false). It put every.libin the installed tree on every link line, including a 339 MB webrtc static library on projects with no reference into it. Each project names what it links inDirectory.Build.targets; the lists came from what the built binaries actually import. Statics leave no import trace, soZXing.libwas inferred. - webrtc carries a patched libyuv whose
ConvertToI420takes three extra parameters. The webrtc port deliberately does not installinclude/libyuv.h; the compiled files include it by full path. Seeduplicated-libraries.md. - applocal does not populate the app's own output folder, and does not run at all when the
linker is skipped or a project is only queried for packaging outputs. The DLLs are declared
explicitly instead, which is what let
Libraries/vcpkg.patchbe deleted. - libvlc plugins cannot be flattened. Their relative paths are recorded in the generated
plugins.dat, so they reach the package throughContentitems withLinkmetadata. *.patchmust stay LF.git applyrejects a patch whose line endings were converted; this is whyLibraries/vcpkg.patchhad stopped applying. Pinned in.gitattributesin both repos.Telegram.Stub's native AOT needsvswhereon PATH —findvcvarsall.batcalls it bare, so a build from a plain shell fails where Visual Studio or a developer prompt succeeds.