Merge branch 'master' of https://github.com/microsoft/vcpkg into dev/grdowns/5580

2 files changed, 4 insertions, 4 deletions

diff --git a/docs/specifications/export-command.md b/docs/specifications/export-command.md
index aaa95cb1c..4111bfed4 100644
--- a/docs/specifications/export-command.md
+++ b/docs/specifications/export-command.md
@@ -5,7 +5,7 @@
 ### A. Build once and share
 
 Customers want to be able to build their set of required libraries once, and then distribute the resulting binaries to all members of the "group". This has been brought up in
-- Enterprise environments, in which there are dedicated teams to acquire libraries and then share them with other team to consume them
+- Enterprise environments, in which there are dedicated teams to acquire libraries and then share them with other teams to consume them
 - Academic environments, in which the professor/teacher wants to build the required libraries and then provide them to all the students
 - CI Systems, in which developers want to quickly distribute their exact set of dependencies to a cloud-based farm of build machines
 
@@ -167,6 +167,6 @@ Alice gives to Bob: a) The links to her project and b) The zip file "vcpkg-expor
 ## 5. Technical model
 
 - Each exported library, must be accompanied with all of its dependencies, even if they are not explicitly specified in the `vcpkg export` command.
-- When exporting a library, a dependency graph will be built, similarly to install, to figure out which packages needs to be exported.
+- When exporting a library, a dependency graph will be built, similarly to install, to figure out which packages need to be exported.
 - It is allowed to have packages from different triplets, so users can include 32/64-bit and dynamic/static binaries in the same export.
 - The exported archives also include the files needed to integrate with MSBuild and/or CMake.
\ No newline at end of file
diff --git a/docs/specifications/feature-packages.md b/docs/specifications/feature-packages.md
index 198a602ba..81afba080 100644
--- a/docs/specifications/feature-packages.md
+++ b/docs/specifications/feature-packages.md
@@ -1,6 +1,6 @@
 # Proposal: Features / Feature packages (Feb 23 2017)

 

-**Note: this is the proposal as it was initially accepted and does not neccessarily reflect the current behavior.**

+**Note: this is the proposal as it was initially accepted and does not necessarily reflect the current behavior.**

 

 ## 1. Motivation

 

@@ -14,7 +14,7 @@ Therefore, there is significant value in enabling users to choose whether they f
 

 The community around [OpenCV][] has built up a library of extensions called [OpenCV_contrib][]. However, these extensions are a source-level patch onto the main OpenCV codebase and therefore must be applied _during_ the core OpenCV build. Further confounding the problem, it is the author's understanding that these community extensions have only been developed with [CUDA][] enabled and cannot be built without that dependency.

 

-Therefore, if CUDA is disabled, OpenCV\_contrib must also be disabled. Likewise, when a user requests OpenCV\_contrib, CUDA must be enabled. It would be convienent, but not a requirement, to enable CUDA without enabling the community extensions.

+Therefore, if CUDA is disabled, OpenCV\_contrib must also be disabled. Likewise, when a user requests OpenCV\_contrib, CUDA must be enabled. It would be convenient, but not a requirement, to enable CUDA without enabling the community extensions.

 

 Finally, these extensions add additional exports and headers which could be depended upon by other libraries. For maintainers, there must be a way to specify this requirement such that `vcpkg install mylib-depends-ocv-contrib` will verify/build/rebuild OpenCV with the community extensions enabled.