[PR #15855] Move our big OSS dependencies to vcpkg #30756

Open
opened 2026-01-31 09:42:46 +00:00 by claunia · 0 comments
Owner

Original Pull Request: https://github.com/microsoft/terminal/pull/15855

State: closed
Merged: Yes


This pull request removes the following vendored open source, in favor
of getting it from vcpkg:

  • CLI11 2.4
  • jsoncpp 1.9
  • fmt 7.1.3
  • gsl 3.1 (not vendored, but submoduled--arguably worse!)

Now that Visual Studio 2022 includes a built-in workload for vcpkg, the
onboarding process is much smoother. Terminal should only require the
vcpkg workload.

I've added some build rules that detect vcpkg via VS and via the user's
environment before falling back to a location in the source tree. The CI
pipeline will fall back to installing and bootstrapping vcpkg in
dep/vcpkg if necessary.

Some OSS has not been (and will not be) migrated:

  • wyhash: ours is included directly in til/hash
  • pcg_random: we have a stripped down copy compared to vcpkg
  • stb_rect: vcpkg only ships all of STB; ours is a stripped down copy
  • chromium numerics: vcpkg does not ship Chromium, especially not this
    tiny fraction of Chromium
  • dynamic_bitset and libpopcnt: removing in #17510
  • interval_tree: no vcpkg equivalent

To support the needs of the inbox Windows build, I've split up our vcpkg
manifest into dependencies for all projects and dependencies just for
Terminal. To support this, we now offer a terminal feature. The vcpkg
rules in common.build.pre.props are set up to turn it on, whereas the
build rules we eventually write for the OS will not be.

Most of the work is concentrated in common.build.pre.props.

**Original Pull Request:** https://github.com/microsoft/terminal/pull/15855 **State:** closed **Merged:** Yes --- This pull request removes the following vendored open source, in favor of getting it from vcpkg: - CLI11 2.4 - jsoncpp 1.9 - fmt 7.1.3 - gsl 3.1 (not vendored, but submoduled--arguably worse!) Now that Visual Studio 2022 includes a built-in workload for vcpkg, the onboarding process is much smoother. Terminal should only require the vcpkg workload. I've added some build rules that detect vcpkg via VS and via the user's environment before falling back to a location in the source tree. The CI pipeline will fall back to installing and bootstrapping vcpkg in dep/vcpkg if necessary. Some OSS has not been (and will not be) migrated: - wyhash: ours is included directly in til/hash - pcg_random: we have a stripped down copy compared to vcpkg - stb_rect: vcpkg only ships *all of STB*; ours is a stripped down copy - chromium numerics: vcpkg does not ship Chromium, especially not this tiny fraction of Chromium - dynamic_bitset and libpopcnt: removing in #17510 - interval_tree: no vcpkg equivalent To support the needs of the inbox Windows build, I've split up our vcpkg manifest into dependencies for all projects and dependencies just for Terminal. To support this, we now offer a `terminal` feature. The vcpkg rules in `common.build.pre.props` are set up to turn it on, whereas the build rules we eventually write for the OS will not be. Most of the work is concentrated in `common.build.pre.props`.
claunia added the pull-request label 2026-01-31 09:42:46 +00:00
Sign in to join this conversation.
No Label pull-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#30756