Move our big OSS dependencies to vcpkg #15855

DHowett · 2023-08-21T00:13:18Z

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 A minor ConPTY refactoring: Goodbye VtEngine Edition #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.

src/common.build.post.props

@@ -113,4 +113,7 @@
      <ForcedIncludeFiles>$(SolutionDir)\bin\$(Configuration)\inc\TilFeatureStaging.h;%(ForcedIncludeFiles)</ForcedIncludeFiles>
    </ClCompile>
  </ItemDefinitionGroup>
+
+  <!-- For C++ projects, bring in the vcpkg targets at the end -->
+  <Import Project="$(VcpkgRoot)/scripts/buildsystems/msbuild/vcpkg.targets" Condition="'$(MSBuildProjectExtension)'=='.vcxproj'" />


src/common.build.pre.props

+      Since we link everything statically, we don't need to copy anything.
+      This saves running a powershell script for every project.
+    -->
+    <VcpkgApplocalDeps>false</VcpkgApplocalDeps>


src/common.build.pre.props

+      Since we link everything statically, we don't need to copy anything.
+      This saves running a powershell script for every project.
+    -->
+    <VcpkgApplocalDeps>false</VcpkgApplocalDeps>


src/common.build.pre.props

+    <CAExcludePath>$(CAExcludePath);$(VcpkgInstalledDir)</CAExcludePath>
+  </PropertyGroup>
+
+  <Import Project="$(VcpkgRoot)/scripts/buildsystems/msbuild/vcpkg.props" Condition="'$(MSBuildProjectExtension)'=='.vcxproj'" />


build/pipelines/templates-v2/steps-install-vcpkg.yml

src/common.build.pre.props

zadjii-msft · 2024-07-22T15:35:03Z

oh no we forgot to do the .editorconfig thing

`nuget restore` actually runs through MSBuild! However, #15855 added a dependency from our project on a system-installed _or locally detected_ `vcpkg.targets` (or `.props`). Our build runs `nuget restore` before finding or installing vcpkg, so the rules in our project file would try to import vcpkg before it had been found (or installed). On build agents with vcpkg installed via the VS workload, this was fine: we would import the one that came with VS and go on our merry way. On build agents where it needs to be installed locally, it could not be imported. The fix in this PR is to install/bootstrap vcpkg before running nuget. I tried to isolate the vcpkg rules to only run _in the absence of nuget_, but that didn't work.