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.
Refactoring in commit 584ab528 (VS: Add internal API to get platform
toolset as string, 2016-10-18) accidentally changed the semantics of the
original `cmGlobalVisualStudio10Generator::GetPlatformToolset`
implementation to return a pointer to an empty string instead of
`nullptr` when no toolset is configured. This broke cases that tested
for `nullptr` to detect the lack of any specific toolset, such as the
call in `Find64BitTools`. Restore the `nullptr` return in this case.
MSBuild interprets the `.vcxproj` content based on the `PlatformToolset`
setting, so our reverse mapping needs to be based on that setting too.
For VS 2010 and above, choose the flag map to match the toolset name
rather than the generator VS version.
Issue: #16153
Visual Studio provides toolchains that are themselves built for 32-bit
or 64-bit host architectures. By default it uses the 32-bit tools, but
it can be told to prefer the 64-bit tools on 64-bit hosts. Extend the
`CMAKE_GENERATOR_TOOLSET` specification to provide a way to request
use of the 64-bit host tools.
Closes: #15622
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.
Since commit 059c230d (VS: Explicitly default to v100 toolset in Visual
Studio 2010, 2016-07-21) the VS 2010 generator now correctly defaults to
the v100 toolset instead of no toolset. However, this broke our logic
for defaulting to the `Windows7.1SDK` toolset for 64-bit builds on VS
2010 Express. Fix the logic by ignoring the `v100` default in the case.
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
Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
The clang-format tool can do a good job formatting most code, but
well-organized streaming blocks are best left manually formatted.
Find blocks of the form
os <<
"...\n"
"...\n"
;
using the command
$ git ls-files -z -- Source |
egrep -v -z '^Source/kwsys/' |
xargs -0 pcregrep -M --color=always -B 1 -A 1 -n \
'<<[^\n]*\n(^ *("[^\n]*("|<<|;)$|;)\n){2,}'
Find blocks of the form
os << "...\n"
<< "...\n"
<< "...\n";
using the command
$ git ls-files -z -- Source |
egrep -v -z '^Source/kwsys/' |
xargs -0 pcregrep -M --color=always -B 1 -A 1 -n \
'<<[^\n]*\n(^ *<<[^\n]*(\\n"|<<|;)$\n){2,}'
Surround such blocks with the pair
/* clang-format off */
...
/* clang-format on */
in order to protect them from update by clang-format. Use the C-style
`/*...*/` comments instead of C++-style `//...` comments in order to
prevent them from ever being swallowed by re-formatting of surrounding
comments.
Sort include directives within each block (separated by a blank line) in
lexicographic order (except to prioritize `sys/types.h` first). First
run `clang-format` with the config file:
---
SortIncludes: false
...
Commit the result temporarily. Then run `clang-format` again with:
---
SortIncludes: true
IncludeCategories:
- Regex: 'sys/types.h'
Priority: -1
...
Commit the result temporarily. Start a new branch and cherry-pick the
second commit. Manually resolve conflicts to preserve indentation of
re-ordered includes. This cleans up the include ordering without
changing any other style.
Use the following command to run `clang-format`:
$ git ls-files -z -- \
'*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' |
egrep -z -v '(Lexer|Parser|ParserHelper)\.' |
egrep -z -v '^Source/cm_sha2' |
egrep -z -v '^Source/(kwsys|CursesDialog/form)/' |
egrep -z -v '^Utilities/(KW|cm).*/' |
egrep -z -v '^Tests/Module/GenerateExportHeader' |
egrep -z -v '^Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h' |
xargs -0 clang-format -i
This selects source files that do not come from a third-party.
Inspired-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
The -T parameter to CMake may now be specified through cmake-gui via a
new text field in the first-time configure wizard (below the generator
chooser).
The generator factories specify whether or not they support toolsets.
This information is propagated to the Qt code and used to determine if
the selected generator should also display the optional Toolset widgets.
Refactor the local generator creation API to accept a
cmState::Snapshot. Adjust MakeLocalGenerator to use the 'current'
snapshot in cases where there is no parent. Create the snapshot
for subdirectories in cmMakefile::AddSubdirectory.
This means that snapshots are now created at the point of extending the tree,
as appropriate, and independently of the cmLocalGenerator and cmMakefile they
represent the state for.
We never implemented them for VS 11 (2012), 12 (2013), or 14 (2015).
For VS 10 (2010) the reload macro does not work correctly when run from
inside a build launched through the IDE because stopping the build kills
the CMake that is driving the reload. Fortunately VS >= 10 know how to
reload the whole solution anyway.
* Re-order VS generators from newest to oldest.
* Show how to specify a VS generator with a target platform
* Increase the option output indentation to avoid extra wrapping
with longer generator names.
The Ninja build system does not support a in-file verbositiy switch.
Instead teach 'cmake --build' to extract the CMAKE_VERBOSE_MAKEFILE
setting and pass it as an optional '-v' argument to Ninja. This can
serve as a reasonable fallback.
Signed-off-by: Gregor Jasny <gjasny@googlemail.com>
CMake requires both the Desktop SDK and the correct platform SDK
(Windows Phone or Windows Store) to be installed when targeting the
Windows mobile platforms. Verify that the right platform components are
installed and give a more detailed error message when something is
wrong.
Nsight Tegra 2.0 will be revision '8'. Generate this revision number
and add a NsightTegraUpgradeOnceWithoutPrompt element to tell newer
versions not to prompt when upgrading the generated project file.
When CMAKE_SYSTEM_NAME is 'Android', check for an installation of
'NVIDIA Nsight Tegra Visual Studio Edition' and generate .vcxproj
files for the "Tegra-Android" platform. Also make the installed
version available in a CMAKE_VS_NsightTegra_VERSION variable.
When CMAKE_SYSTEM_NAME is 'WindowsCE':
* Set the Subsystem and EntryPointSymbol accordingly.
* When CMAKE_SYSTEM_VERSION is 8.0 (Windows CE 2013),
select the CE800 toolset by default.
For VS generator names that do not specify the platform name, read
CMAKE_GENERATOR_PLATFORM to get it.
Extend the RunCMake.GeneratorPlatform test with a case covering
use of the x64 platform when the test generator is a Visual Studio
generator whose name does not specify a platform.
Rename the 'PlatformName' member to 'DefaultPlatformName' and make
sure it is only read through a 'GetPlatformName()' call. This will
allow non-default names to be chosen later.
Move handling of an empty toolset name into the implementation of the
method. This simplifies the VS 10 implementation of default toolset
selection because it has one code path that is always called.
Move the member from cmGlobalVisualStudio10Generator to
cmGlobalVisualStudio7Generator to make it useful for earlier
versions of VS. Set the member to true only starting with
cmGlobalVisualStudio8Generator since we will not implement
MASM support for versions less than VS 8.
Teach the VS >= 10 generators to recognize these system names and select
the appropriate default toolset for the system version. Report an error
when the version is not known to be supported by VS.
Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
Add boolean members to the VS >= 10 global generator to save
whether CMAKE_SYSTEM_NAME is WindowsPhone or WindowsStore
without having to repeat a string comparison.
Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
Add a virtual cmGlobalVisualStudio10Generator::InitializeSystem method
called from SetSystemName once the SystemName and SystemVersion members
have been populated. This will give VS version-specific generators a
chance to recognize and adapt to the target system.
Ask the global generator during generation instead of trying
to store it up front. Later the global generator may not know
the platform name when it is creating the local generator.
Move the definition of CMAKE_VS_PLATFORM_NAME and other variables that
are not needed by CMakeDetermineSystem out of the AddPlatformDefinitions
method and into a SetSystemName method. The latter may later use
CMAKE_SYSTEM_NAME to decide what platform-specific definitions to add.
Remove the general infrastructure for these additional platform
definitions and hard-code the only two special cases that used
it. They are only for historical reasons so no new such cases
should be added.
Delay use of CMAKE_GENERATOR_TOOLSET until the CMakeSystem.cmake
file has been configured and loaded during the first project() or
enable_language() command. This gives the toolchain file named by
CMAKE_TOOLCHAIN_FILE a chance to set CMAKE_GENERATOR_TOOLSET. This
point is still early enough to set the generator toolset prior to
the initialization of any languages that might use the toolset.
The cmake::GeneratorToolset member variable remains an indication
of what was specified by the -T option or loaded from the cache.
It does not need to be updated based on the toolchain file setting.
The cmMakefile::TryCompile can still pass cmake::GeneratorToolset
into the inner instance because the try-compiled project will do
platform and language initialization using the CMakeSystem module
configured for the outer project.
Extend the RunCMake.GeneratorToolset test with cases that use a
toolchain file to set CMAKE_GENERATOR_TOOLSET.
Divide the cmGlobalVisualStudio10Generator "PlatformToolset" member into
two members representing the generator-selected default toolset and the
user-specified CMAKE_GENERATOR_TOOLSET value. Prefer the user-specified
value, if any, and then fall back to the generator-selected default.
Since commit 5f5c92b9 (VS: Add internal APIs to find MSBuild,
devenv/VCExpress, and msdev, 2013-11-13) the VS generators have
known how to lookup the locations of their build tools directly.
Expose this information to CMake language code by defining new
variables to hold the paths to these tools.
Drop the "Modules/CMakeVS*FindMake.cmake" files. Override the
cmGlobalGenerator::FindMakeProgram method for VS generators to use their
internal APIs to locate the build tool. Set the CMAKE_MAKE_PROGRAM as a
normal variable for use by project code, but do not cache it. This will
allow CMake and CTest to select the proper tool at build time.
Add a cmGlobalGenerator::SelectMakeProgram method to select a
caller-provided make program, the CMAKE_MAKE_PROGRAM cache entry, or a
generator-provided default. Call it from all implementations of the
GenerateBuildCommand method with the corresponding generator's default,
if any.
All cmGlobalGenerator::GenerateBuildCommand call sites that need to
produce a string now generate "cmake --build" commands. The remaining
call sites immediately pass the result to cmSystemTools::RunSingleCommand.
Avoid the intermediate string and argument parsing by directly producing a
vector of strings. Also drop the ignoreErrors argument because no call
sites remain that use it.
Rename the Visual Studio >= 10 generators to indicate the version year:
Visual Studio 10 => Visual Studio 10 2010
Visual Studio 11 => Visual Studio 11 2012
Visual Studio 12 => Visual Stduio 12 2013
Report the names with the year to the list of available generators so
that the cmake-gui drop-down shows the years. When selecting a
generator from the "-G" option or from an existing CMAKE_GENERATOR cache
entry, recognize names without the years for compatibility and map them
to the names with years.
Update the generator names in the cmake-generators.7 manual.
Since we do not need the information about the target architecture
we can use the PlatformName only to specify the this information.
This also removes setting of the MSVC_*_ARCHITECTURE_ID variable
which is not required, because this variable gets set by the
compiler detection code in CMAKE_DETERMINE_COMPILER_ID_CHECK().
Add to the brief documentation of the Visual Studio 10, 11, and 12
generators the corresponding VS product year. Clarify that VS11 is for
Visual Studio 2012, and VS12 is for Visual Studio 2013.
Use cmVisualStudioSlnParser in GenerateBuildCommand() to provide correct
command line for MSBuild even when target project is stored in a
subdirectory.
Extend the cmGlobalGenerator::GenerateBuildCommand virtual method
signature with a "projectDir" parameter specifying the top of the
project build tree for which the build command will be generated.
Populate it from call sites in cmGlobalGenerator::Build where a
fully-generated build tree should be available.
The VS version we generate in the .sln header is used by VS when opening
the file through Windows Explorer and possibly elsewhere. Fix our
generators to use version strings known to VS to avoid a drop-down box.
For VS 10, since commit 4f96af44 (Fix VS 10 .sln files for Windows
Explorer, 2009-10-22) we use "Visual Studio 2010" instead of just
"Visual Studio 10". This is correct except that for the Express edition
we need "Visual C++ Express 2010".
For VS 11, since commit f0d66ab4 (VS11: Fix comment generated at the top
of *.sln files, 2011-10-20) we use "Visual Studio 11" in the .sln header
but the preferred value is "Visual Studio 2012" (just as the first
commit mentioned above fixed for VS 10). Also for the Express edition
we need "Visual Studio Express 2012 for Windows Desktop".
Implement generator toolset selection (cmake -T) for VS >= 10 by setting
the PlatformToolset. Extend the RunCMake.GeneratorToolset test case to
verify CMAKE_GENERATOR_TOOLSET when the generator supports -T.
Since commit 485a940e (VS: Simplify MSVC version reporting, 2012-08-23)
all MSVC version information is detected during the compiler id step
from the actual compiler invoked by generated build systems rather than
hard-coded in VS generators. Therefore we can set the PlatformToolset
in VS >= 10 project files and support toolsets from other VS versions.
Use the registry entries that vsvars32.bat uses to detect the location of
MSBuild.exe in the framework directory. Invoke MSBuild with the option
/p:VisualStudioVersion=$version
so it knows from which VS version to load the system build rules. Teach
cmGlobalVisualStudio11Generator to set its ExpressEdition member using the
registry.
Teach Windows-cl.cmake to use CMAKE_(C|CXX)_COMPILER_VERSION to set the
"MSVC##" and MSVC_VERSION variables. It no longer needs the IDE generator
to dictate the version or to detect the version by running the
command-line tool for NMake and Ninja generators. Drop configuration of
CMakeCPlatform.cmake and CMakeCXXPlatform.cmake from Windows-cl.cmake.in
because all the results it saved are now cheap to compute every time.
