| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* 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.
|
|
|
|
| |
Use `auto` for complex types.
|
|
|
|
|
|
|
|
| |
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'
|
|
|
|
|
|
|
|
| |
When requesting an SDK version which is not suitable (e.g., missing
`windows.h`), CMake will use the next-best SDK version. Output a message
when CMake chooses something different than the requested SDK version.
See #16895.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Define a `CMAKE_WINDOWS_KITS_10_DIR` environment variable to allow
users to tell CMake about a custom Windows 10 SDK directory. We
choose to make this an environment variable rather than a CMake
variable or cache entry because:
* Using a custom directory also requires custom external MSBuild
configuration. Therefore users are already configuring a
custom environment.
* The custom directory must be set consistently in all parts of
a build including nested projects. An environment variable
avoids requiring users to thread the setting into nested builds.
Fixes: #16743
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Move `Get*FlagTable` methods to the global generator and have each VS
generator version pre-populate its default flag table.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modern editors provide plenty of ways to visually separate functions.
Drop the explicit comments that previously served this purpose.
Use the following command to automate the change:
$ git ls-files -z -- \
"*.c" "*.cc" "*.cpp" "*.cxx" "*.h" "*.hh" "*.hpp" "*.hxx" |
egrep -z -v "^Source/cmCommandArgumentLexer\." |
egrep -z -v "^Source/cmCommandArgumentParser(\.y|\.cxx|Tokens\.h)" |
egrep -z -v "^Source/cmDependsJavaLexer\." |
egrep -z -v "^Source/cmDependsJavaParser(\.y|\.cxx|Tokens\.h)" |
egrep -z -v "^Source/cmExprLexer\." |
egrep -z -v "^Source/cmExprParser(\.y|\.cxx|Tokens\.h)" |
egrep -z -v "^Source/cmFortranLexer\." |
egrep -z -v "^Source/cmFortranParser(\.y|\.cxx|Tokens\.h)" |
egrep -z -v "^Source/cmListFileLexer\." |
egrep -z -v "^Source/cm_sha2" |
egrep -z -v "^Source/(kwsys|CursesDialog/form)/" |
egrep -z -v "^Utilities/(KW|cm).*/" |
xargs -0 sed -i '/^\(\/\/---*\|\/\*---*\*\/\)$/ {d;}'
This avoids modifying third-party sources and generated sources.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Each source file has a logical first include file. Include it in an
isolated block so that tools that sort includes do not move them.
|
|\
| |
| |
| |
| | |
d7e863c1 VS: Do not fail on Windows 10 with VS 2015 if no SDK is available (#15929)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since commit v3.4.0-rc1~5^2~1 (VS: Add support for selecting the Windows
10 SDK, 2015-09-30) the VS 2015 generator requires a Windows 10 SDK to
be available when CMAKE_SYSTEM_VERSION specifies Windows 10 (e.g. when
building on a Windows 10 host). Howewver, it is possible to install VS
2015 without any Windows 10 SDK. Instead of failing with an error
message about the lack of a Windows 10 SDK, simply tolerate this case
and use the default Windows 8.1 SDK. Since building for Windows Store
still requires the SDK, retain the diagnostic in that case.
|
|\ \
| |/
| |
| |
| |
| |
| | |
a57caf7e VS: Fix Windows 10 SDK version selection (#15831)
ad594de8 cmSystemTools: Add VersionCompareEqual helper
c173e37f VS: Do not select a partial Windows 10 SDK folder (#15831)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In commit v3.4.0-rc1~5^2~1 (VS: Add support for selecting the Windows 10
SDK, 2015-09-30) we added Windows 10 SDK selection choosing the most
recent SDK that is not newer than the target version. This is backward
because it should be up to the application code to not use APIs newer
than the target version. It is up to the build system to provide a SDK
that has at least the APIs expected to be available for the target
version. Furthermore, since the default target version is the host
version of Windows, the old approach breaks when the only SDK available
is for a newer version of Windows.
Fix this by always selecting a Windows 10 SDK if one exists. Use the
SDK for the exact version if is available. Otherwise use the latest
version of the SDK available because that will have at least the APIs
expected for the target version.
|
| |
| |
| |
| |
| | |
Skip SDK candidate folders that do not contain <um/windows.h> as they
are not full SDKs.
|
|/
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
If CMAKE_SYSTEM_VERSION is just "10.0" then use the latest SDK available
since no particular version was requested.
|
|
|
|
|
|
|
|
|
| |
Teach the VS 2015 generator to produce a WindowsTargetPlatformVersion
value. Use the CMAKE_SYSTEM_VERSION to specify the version and if not
set choose a default based on available SDKs. Activate this behavior
when targeting Windows 10.
Co-Author: Brad King <brad.king@kitware.com>
|
|
|
|
|
|
| |
Determine the Desktop SDK for Windows Phone and Windows Store from the
generator instead of the version of the targeted app. This allows to
build a Windows Phone 8.1 app on VS 2015 for example.
|
|
|
|
| |
It is required anyway, so this makes it explicit.
|
|
|
|
| |
Base class implementations for these are identical.
|
| |
|
|
|
|
| |
Port generator factory methods to pass it.
|
|
|
|
|
|
|
| |
Pass the parent though cmGlobalGenerator::CreateLocalGenerator.
This will make it easy to initialize state scopes independent of
cmMakefile.
|
|
|
|
|
|
|
|
|
| |
* 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.
|
| |
|
|
|
|
|
|
| |
Now that we know the year component of this VS version we
can add it to the generator name. For convenience, map
the name without the year to the name with the year.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
Call the generator "Visual Studio 14" without any year because this
version of VS does not provide a year in the product name.
Copy cmGlobalVisualStudio12Generator to cmGlobalVisualStudio14Generator
and update version numbers accordingly. Add the VS14 enumeration value.
Teach the platform module Windows-MSVC to set MSVC14 and document the
variable. Teach module InstallRequiredSystemLibraries to look for the VS
14 runtime libraries.
Teach tests CheckCompilerRelatedVariables, VSExternalInclude, and
RunCMake.GeneratorToolset to treat VS 14 as they do VS 10, 11, and 12.
Co-Author: Pawel Stopinski <diokhan@go2.pl>
|