Visual Studio 2017 supports multiple instances installed on a single
machine. We use the Visual Studio Installer tool to enumerate instances
and select one. Once we select an instance for a given build tree, save
the result in `CMAKE_GENERATOR_INSTANCE` so we can re-configure the tree
with the same instance on future re-runs of CMake.
Fixes: #17268
We now require C++11 support including `override`. Drop use of
the old compatibility macro. Convert references as follows:
git grep -l CM_OVERRIDE -- '*.h' '*.hxx' '*.cxx' |
xargs sed -i 's/CM_OVERRIDE/override/g'
The detection logic added by commit v3.8.0-rc2~14^2 (VS2017: If Win 8.1
SDK is not available, use Win 10 SDK, 2017-02-20) was incomplete. It is
possible for the Win 8.1 SDK registry entry to exist, and even the
directory, but the header files to not actually be installed. Teach
`cmGlobalVisualStudio15Generator::IsWin81SDKInstalled` to verify that
the `windows.h` header actually exists in the SDK directory. We do this
in `cmGlobalVisualStudio14Generator::GetWindows10SDKVersion` for the
Windows 10 SDK already.
Fixes: #16811
We try to choose the Windows SDK version based on the version of Windows
targeted by the build. However, if using VS 2017 without the Windows
8.1 SDK installed then we must fall back to the Windows 10 SDK even when
targeting an older version of Windows.
Inspired-by: gnaggnoyil <gnaggnoyil@gmail.com>
VS 2017 and later may no longer populate the Windows Registry entries
CMake has traditionally used to find the VS installations. This is
because VS now supports having multiple installations of the same
version. The Visual Studio Installer tool provides a COM interface we
can query to locate installations.
Add these (currently unused) tables in preparation for `.csproj`
generation support. Populate the tables for every version with a set of
initial values that work well for me with VS 12 and VS 14. Later we may
need to generate them more thoroughly from MSBuild `.xml` files.
Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
Call the generator "Visual Studio 15" without any year because the
preview version of VS 15 does not provide a year in the product name.
Copy cmGlobalVisualStudio14Generator to cmGlobalVisualStudio15Generator
and update version numbers accordingly. Add the VS15 enumeration value.
Note that we do not need to add a MSVC15 variable or v150 toolset
because Visual Studio 15 comes with an updated version of the v140
toolset and remains ABI-compatible.
Teach tests VSExternalInclude, RunCMake.GeneratorPlatform, and
RunCMake.GeneratorToolset to treat VS 15 as they do VS 10-14.
Closes: #16143
Brad King