Updates

proposed/vcpkg.md

@@ -36,15 +36,16 @@ It would also make it easier for us to contribute our own native projects, like
 ### Non-Goals
 
 - Replace all existing native dependency mechanisms.
-
-Initially, using vcpkg from MSBuild is considered out of scope for this proposal.
+- Initially, using vcpkg from MSBuild is considered out of scope.
+- Using vcpkg in .NET 9 is out of scope.
 
 ## Stakeholders and Reviewers
 
 - @jkoritzinsky
 - @mmitche
 - @jkotas
 - @AaronRobinsonMSFT
+- @wtgodbe
 
 ## Design
 
@@ -70,16 +71,21 @@ All repositories that use vcpkg must use the manifest mode of vcpkg to declare t
 
 ### Source-build partners and conditionally system dependencies
 
-For some dependencies, we may want to use a system-installed version of the dependency in source-build scenarios. For these cases, our source-build partners can remove the dependencies from the vcpkg manifest. Since the CMake integration with vcpkg uses the standard `find_library` and `find_package` CMake commands, the system dependencies will be found instead of the vcpkg dependencies with no change to the CMake source code.
+For some dependencies, we may want to use a system-installed version of the dependency in source-build scenarios.
+For these cases, our source-build partners can remove the dependencies from the vcpkg manifest.
+Since the CMake integration with vcpkg uses the standard `find_library` and `find_package` CMake commands, the system dependencies will be found instead of the vcpkg dependencies with no change to the CMake source code.
 
 ### Flowing native dependencies with binary caching
 
-vcpkg has a binary caching feature that can use NuGet. We should be able to utilize this feature for flowing native dependencies that are consumed by native code (such as `dotnet/llvm-project` assets) to avoid having to run the build through MSBuild to locate the dependencies or rebuilding the dependencies in each repository.
+vcpkg has a binary caching feature that can use NuGet.
+We should be able to utilize this feature for flowing native dependencies that are consumed by native code (such as `dotnet/llvm-project` assets) to avoid having to run the build through MSBuild to locate the dependencies or rebuilding the dependencies in each repository. This is not something that needs to be done immediately, but is something we can consider in the future instead of our existing package flow model.
 
 ## Q & A
 
 - Why use vcpkg instead of another package manager?
-
-  - Vcpkg is already used by many teams at Microsoft, and is already used by many of the dependencies that we may want to consume.
-  - Vcpkg is cross-platform.
-  - Vcpkg allows CMake consumers to consume dependencies as if they were installed on the machine instead of requiring custom CMake logic to find dependencies. Supporting changing a package between a vcpkg and system dependency would require more work with other package managers.
+    - Vcpkg is already used by many teams at Microsoft, and is already used by many of the dependencies that we may want to consume.
+    - Vcpkg is cross-platform.
+    - Vcpkg allows CMake consumers to consume dependencies as if they were installed on the machine instead of requiring custom CMake logic to find dependencies. Supporting changing a package between a vcpkg and system dependency would require more work with other package managers.
+- What is vcpkg's minimum toolset requirements? Do these conflict with the requirements for .NET?
+    - Vcpkg requires CMake 3.14 or newer. We require 3.20 or newer, so we should be fine.
+    - Vcpkg requires a C++ compiler that supports C++17. Although we don't use C++17, all of the compilers we support do support C++17.