Merge branch 'master' of https://github.com/EMCECS/vcpkg

# Conflicts:
#	ports/ecsutil/CONTROL
#	ports/ecsutil/portfile.cmake

3 files changed, 17 insertions, 6 deletions

diff --git a/docs/about/faq.md b/docs/about/faq.md
index ff7ecdba5..0178e051a 100644
--- a/docs/about/faq.md
+++ b/docs/about/faq.md
@@ -35,7 +35,7 @@ To use different versions of a library for different projects, we recommend maki
 
 If your application is very sensitive to the versions of libraries, we recommend checking in the specific set of portfiles you need into your source control along with your project sources and using the `--vcpkg-root` option to redirect the working directory of `vcpkg.exe`.
 
-## How does Vcpkg protect my Privacy?
+## How does Vcpkg protect my privacy?
 See the [Privacy document](privacy.md) for all information regarding privacy.
 
 ## Can I use my own CMake toolchain file with Vcpkg's toolchain file?
@@ -93,7 +93,7 @@ Enabling user-wide integration (`vcpkg integrate install`) changes the default f
 ## Why not NuGet?
 NuGet is a package manager for .NET libraries with a strong dependency on MSBuild. It does not meet the specific needs of Native C++ customers in at least three ways.
 
-- **Compilation Flavors**. With so many possible combinations of compilation options, the task of providing a truly complete set of options is intrinsicly impossible. Furthermore, the download size for reasonably complete binary packages becomes enormous. This makes it a requirement to split the results into multiple packages, but then searching becomes very difficult.
+- **Compilation Flavors**. With so many possible combinations of compilation options, the task of providing a truly complete set of options is intrinsically impossible. Furthermore, the download size for reasonably complete binary packages becomes enormous. This makes it a requirement to split the results into multiple packages, but then searching becomes very difficult.
 
 - **Binary vs Source**. Very closely tied to the first point, NuGet is designed from the ground up to provide relatively small, prebuilt binaries. Due to the nature of native code, developers need to have access to the source code to ensure ABI compatibility, performance, integrity, and debuggability.
 
@@ -108,7 +108,7 @@ Conan.io is a publicly-federated, project-centric, cross-platform, C++ package m
 
 - **Cross-platform vs single-platform**. While being hosted on many platforms is an excellent north star, we believe the level of system integration and stability provided by apt-get, yum, and homebrew is well worth needing to exchange `apt-get install libboost-all-dev` with `brew install boost` in automated scripts. We chose to make our system as easy as possible to integrate into a world with these very successful system managers -- one more line for `vcpkg install boost` -- instead of attempting to replace them where they are already so successful and well-loved.
 
-- **C++/CMake vs python**. While Python is an excellent language loved by many, we believe that transparency and familiarity are the most important factors when choosing a tool as important to your workflow as a package manager. Consequently, we chose to make the implementation languages be as universally accepted as possible: C++ should be used in a C++ package manager for C++ programmers. You should not be required to learn another language just to understand your package manager.
+- **C++/CMake vs python**. While Python is an excellent language loved by many, we believe that transparency and familiarity are the most important factors when choosing a tool as important to your workflow as a package manager. Consequently, we chose to make the implementation languages be as universally accepted as possible: C++ should be used in a C++ package manager for C++ programmers. You should not be required to learn another programming language just to understand your package manager.
 
 ## Why not Chocolatey?
 Chocolatey is an excellent system for managing applications. However, it is not currently designed to acquire redistributable developer assets and help you with debugging. Vcpkg, in comparison, is designed to get you the libraries you need to build your application and help you deliver through any platform you'd like (including Chocolatey!).
diff --git a/docs/examples/packaging-zlib.md b/docs/examples/packaging-zlib.md
index 508947f1a..1d61cfee1 100644
--- a/docs/examples/packaging-zlib.md
+++ b/docs/examples/packaging-zlib.md
@@ -3,7 +3,7 @@
 ### Bootstrap with `create`
 First, locate a globally accessible archive of the library's sources. Zip, gzip, and bzip are all supported. Strongly prefer official sources or mirrors over unofficial mirrors.
 
-*Looking at zlib's website, the URL http://zlib.net/zlib128.zip looks appropriate.*
+*Looking at zlib's website, the URL http://zlib.net/zlib1211.zip looks appropriate.*
 
 Second, determine a suitable package name. This should be ASCII, lowercase, and recognizable to someone who knows the library's "human name". If the library is already packaged in another package manager, prefer that name.
 
@@ -11,7 +11,7 @@ Second, determine a suitable package name. This should be ASCII, lowercase, and
 
 Finally, if the server's name for the archive is not very descriptive (such as downloading a zipped commit or branch from GitHub), choose a nice archive name of the form `<packagename>-<version>.zip`.
 
-*`zlib128.zip` is a fine name, so no change needed.*
+*`zlib1211.zip` is a fine name, so no change needed.*
 
 All this information can then be passed into the `create` command, which will download the sources and bootstrap the packaging process inside `ports\<packagename>`.
 
@@ -26,7 +26,7 @@ In addition to the generated `ports\<package>\portfile.cmake`, we also need a `p
 *For zlib2, we'll create the file `ports\zlib2\CONTROL` with the following contents:*
 ```no-highlight
 Source: zlib2
-Version: 1.2.8
+Version: 1.2.11
 Description: A Massively Spiffy Yet Delicately Unobtrusive Compression Library
 ```
 
diff --git a/docs/users/triplets.md b/docs/users/triplets.md
index 70580df46..2bb9c74b3 100644
--- a/docs/users/triplets.md
+++ b/docs/users/triplets.md
@@ -41,6 +41,16 @@ This can be set to `v141`, `v140`, or left blank. If left blank, we select the l
 Visual Studio 2015 platform toolset is `v140`  
 Visual Studio 2017 platform toolset is `v141`
 
+### VCPKG_VISUAL_STUDIO_PATH
+Specifies the Visual Studio installation to use.
+
+When unspecified, a Visual Studio instance is selected automatically, preferring Stable 2017, then Preview 2017, then 2015.
+
+The path should be absolute, formatted with backslashes, and have no trailing slash:
+```cmake
+set(VCPKG_VISUAL_STUDIO_PATH "C:\\Program Files (x86)\\Microsoft Visual Studio\\Preview\\Community")
+```
+
 ### VCPKG_CHAINLOAD_TOOLCHAIN_FILE
 Specifies an alternate CMake Toolchain file to use.
 
@@ -52,6 +62,7 @@ See also the CMake documentation for toolchain files: https://cmake.org/cmake/he
 Sets additional compiler flags to be used when not using `VCPKG_CHAINLOAD_TOOLCHAIN_FILE`.
 
 This option also has forms for configuration-specific and C flags:
+- `VCPKG_CXX_FLAGS`
 - `VCPKG_CXX_FLAGS_DEBUG`
 - `VCPKG_CXX_FLAGS_RELEASE`
 - `VCPKG_C_FLAGS`