| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is generated by a python script that uses regular expressions to
search for string concatenation patterns of the kind
```
std::string str = <ARG0>;
str += <ARG1>;
str += <ARG2>;
...
```
and replaces them with a single `cmStrCat` call
```
std::string str = cmStrCat(<ARG0>, <ARG1>, <ARG2>, ...);
```
If any `<ARGX>` is itself a concatenated string of the kind
```
a + b + c + ...;
```
then `<ARGX>` is split into multiple arguments for the `cmStrCat` call.
If there's a sequence of literals in the `<ARGX>`, then all literals in the
sequence are concatenated and merged into a single literal argument for
the `cmStrCat` call.
Single character strings are converted to single char arguments for
the `cmStrCat` call.
`std::to_string(...)` wrappings are removed from `cmStrCat` arguments,
because it supports numeric types as well as string types.
`arg.substr(x)` arguments to `cmStrCat` are replaced with
`cm::string_view(arg).substr(x)`
|
| |
|
| |
|
|
|
|
| |
Reduce the number of files relying on `cmake.h`.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
9040df31e2 Merge branch 'backport-fix-custom-target-with-csharp'
1acd1c2b50 CSharp: Fix regression in VS project type selection for custom target
a56edad6d6 CSharp: Fix regression in VS project type selection for custom target
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2549
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A target created by `add_custom_target` should always be a `.vcxproj`
file even if it has `.cs` sources involved in custom commands and such.
The latter case was broken by refactoring in commit v3.12.0-rc1~160^2~7
(remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget,
2018-03-19). The reason is that the `HasLanguage` method added by
commit v3.12.0-rc1~239^2~6 (cmGeneratorTarget: add HasLanguage() as
wrapper for GetLanguages(), 2018-03-19) does not check the target type
and so is not a suitable check for deciding the project file extension.
The `HasLanguage` method was an attempt at an abstraction that turns
out not to work very well. Replace it with a dedicated `IsCSharpOnly`
method that considers the target type, sources, and non-transitive
`LINKER_LANGUAGE`.
Fixes: #18515
|
|/
|
|
|
| |
Record backtraces for "utility" dependencies created by
`add_dependencies` calls.
|
| |
|
|
|
|
| |
Use `auto` for complex types.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some are user facing.
Found using
codespell -q 3 --skip="./Utilities" -I .cmake-whitelist.txt`
whereby the whitelist contained:
ans
dum
helpfull
emmited
emmitted
buil
iff
isnt
nto
ot
pathes
substract
te
todays
upto
whitespaces
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit v3.9.0-rc1~309^2 (include_external_msproject: Honor
MAP_IMPORTED_CONFIG_<CONFIG>, 2017-04-04) we accidentally honor
`MAP_IMPORTED_CONFIG_<CONFIG>` while generating the `.sln` file entries
for normal targets. This causes `devenv.com`-driven builds to use the
mapping incorrectly for normal targets. Check that a target really
comes from `include_external_msproject` before considering the map.
Furthermore, when we do use the map, we should only take the first entry
if more than one configuration is specified. Otherwise we end up giving
VS a configuration name with a `;` in it.
Fixes: #17276
|
|
|
|
| |
This generator has been deprecated since CMake 3.6. Remove it.
|
|
|
|
|
| |
This allows projects added via `include_external_msproject` to compile
the preferred configuration despite different naming conventions.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| | |
f27492a4 VS: Add internal API for detecting "managed" projects
4f78b9ff VS: Add CSharp project uuid and file extension
|
| |
| |
| |
| |
| | |
This is in preparation for adding CSharp language support to the VS
generator.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
e1c77472 Format include directive blocks and ordering with clang-format
180538c7 Source: Stabilize include order
0e7bca92 Utilities/Release: Stabilize include order in WiX custom action
eb817be0 Tests: Stabilize include order in MFC, VSXaml, and VSWinStorePhone
eda313b4 Tests: Stabilize include order in StringFileTest
7110b754 CursesDialog: add missing cmState include
d7a5f255 Modules: Remove unused CMakeTestWatcomVersion.c file
|
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
| |
Update documentation to mark the generator deprecated. Add a warning at
the end of generation plus an option to turn off the warning.
|
|
|
|
|
| |
It's not actually the first target in a `.sln` file that is treated as
the default startup project, but rather the first fully defined target.
|
|
|
|
|
|
|
|
| |
Add a `VS_STARTUP_PROJECT` directory property to specify the project
that should be placed first in the `.sln` file so that it will be
selected as the default startup project.
Co-Author: Taylor Braun-Jones <taylor.braunjones@avigilon.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Mostly automated:
values=( "EXECUTABLE" "STATIC_LIBRARY" "SHARED_LIBRARY" "MODULE_LIBRARY" "OBJECT_LIBRARY" "UTILITY" "GLOBAL_TARGET" "INTERFACE_LIBRARY" "UNKNOWN_LIBRARY" "TargetType")
for i in "${values[@]}"; do git grep -l cmTarget::$i | xargs sed -i "s|cmTarget::$i|cmState::$i|g"; done
|
|
|
|
|
|
|
|
| |
Refactor cmGlobalVisualStudioGenerator::TargetCompare to store the name of
the target that should come first instead of hard-coding "ALL_BUILD".
Update client sites to specify "ALL_BUILD" when ordering for .sln files
and an empty string otherwise (in cases when "ALL_BUILD" should not be
encountered anyway).
|
| |
|
| |
|
|
|
|
| |
It is required anyway, so this makes it explicit.
|
|
|
|
|
|
|
|
|
|
|
| |
Drop the VS >= 7 generator's global Configurations member and instead
lookup configurations using cmMakefile::GetConfigurations where needed.
This avoids accumulating all CMAKE_CONFIGURATION_TYPES values ever
encountered by a project() or enable_language() command and allows
the final value to be used in each directory. We don't officially
support per-directory CMAKE_CONFIGURATION_TYPES values but we certainly
should not generate configurations not in the final value in the top
level directory.
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Revert commit v3.2.0-rc1~165^2 (Encoding: Write Visual Studio solution
file with BOM, 2014-12-26). The BOM breaks the VS IDE version selector
when loading the .sln from Windows Explorer.
|
|
|
|
|
|
|
|
| |
When configured to use UTF-8 internally, add a UTF-8 BOM
to generated .sln files for Visual Studio to correctly
handle them.
Otherwise, some versions of Visual Studio will read them
as ANSI encoded files.
|
|
|
|
|
| |
The cmGlobalVisualStudio7Generator::WriteTargetConfigurations
'root' parameter is no longer used, so remove it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Casts from std::string -> cmStdString were high on the list of things
taking up time. Avoid such implicit casts across function calls by just
using std::string everywhere.
The comment that the symbol name is too long is no longer relevant since
modern debuggers alias the templates anyways and the size is a
non-issue since the underlying methods are generated since it's
inherited.
|