| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Previously, different versions of VS Generators checked whether a target
was in .sln file or not by checking whether the target was to be written
to build system or not.
As we move `ZERO_CHECK.vcxproj` to `.proj`, we want to exclude those
files from being written to `.sln` files too. This commit introduces
`IsInSolution()` at `cmGlobalVisualStudioGenerator` level which can be
customized at specific versioned Generator when needed.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Make `cmCustomCommand` have just only default constructor.
Use each setter instead. This follows the builder pattern.
Introduce `cc::SetOutputs(std::string output)`.
This will be used later, as substitution for `cc::SetOutputs({output})`.
|
| |
|
|
|
|
| |
Fixes: #22339
|
| |
|
|
|
|
|
|
| |
Add a `cmGeneratorTarget::IsInBuildSystem` helper method to tell
generators whether a target should participate in the generated build
system.
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
b69010b719 VS: Fix .sln support for VS Version Selector with VS 2019
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4844
|
| |
| |
| |
| |
| |
| | |
VS 2019 changed the naming pattern used by 2015 and 2017.
Fixes: #20783
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
88ad02f1ec VS: Restore .sln support for VS Version Selector
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4765
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | |
| | | |
88ad02f1ec VS: Restore .sln support for VS Version Selector
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4765
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since commit 3b51343ea1 (VS: Emit UTF-8 BOM for generated solution files,
2019-08-19, v3.16.0-rc1~237^2) the `.sln` file does not work with the
VS Version Selector. Add a newline after the BOM to restore support.
Fixes: #20725
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Adds a flag to indicate that pipe output from a custom command should be
interpreted as UTF-8 encoded. This change does not introduce a public
way to set the flag, but generators that create internally-generated
commands know if they are calling cmake, which uses UTF-8 pipes.
MSBuild added support for interpreting output of PreBuildEvent,
PreLinkEvent, PostBuildEvent, and CustomBuildStep as UTF-8. This change
will appear in Visual Studio 16.6 Preview 3. It is opt-in, and you need
to add the StdOutEncoding tag. MSBuild treats these as property bags so
if we emit the tag for earlier versions of Visual Studio it would be
safely ignored. This change emits the StdOutEncoding tag and sets it to
UTF-8 whenever the custom command UTF-8 pipe flag is set. This fixes
globalization issues when the output from cmake contained characters
that required MSBuild to interpret as UTF-8 before displaying them.
|
| |/
|/| |
|
| |
| |
| |
| | |
Fixes: #20345
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Move custom command creation to cmLocalGenerator and dispatch custom
commands in cmMakefile to generate time. Generators add custom commands
using the new methods provided by cmLocalGenerator.
Issue: #12877
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since commit 97cc29c766 (VS: Teach generators how to mark per-config
source files, 2017-04-10, v3.9.0-rc1~268^2~2) the VS generators have
known how to generate per-config sources. We've now converted most
other code paths to support per-config sources, so drop the check
that disallows it.
This leaves only per-config support for precompiled headers and unity
build transformations, but those are optional features that can be
addressed later.
Fixes: #18233
Issue: #19789
|
|/ |
|
|
|
|
|
| |
Run the `clang-format.bash` script to update our C and C++ code to a new
include order `.clang-format`. Use `clang-format` version 6.0.
|
|\
| |
| |
| |
| |
| |
| |
| | |
Resolve conflicts with changes since the 3.15 series:
* Convert `cmSystemTools::IsOn` => `cmIsOn`.
* Move one "EXCLUDE_FROM_ALL" target property logic fix to
its new location in `cmMakefile::AddNewUtilityTarget`.
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The "all" target in each directory is supposed to have targets from that
directory even if the directory itself is marked `EXCLUDE_FROM_ALL` in
its parent. This was broken by commit dc6888573d (Pass EXCLUDE_FROM_ALL
from directory to targets, 2019-01-15, v3.14.0-rc1~83^2) which made the
participation of a target in "all" independent of context. Revert much
of the logic change from that commit to restore the old behavior. Then
re-implement the behavior intended by the commit to keep its test
working. Extend the test to cover the old behavior too.
Fixes: #19753
|
| | | |
|
| | |
| | |
| | |
| | | |
The enumerations will also be used in cmLocalGenerator.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7847fef510 VS: Fix access violation when calling Visual Studio macro
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3853
|
| | | |
| | | |
| | | |
| | | | |
Fixes: #19730
|
|/ / /
| | |
| | |
| | |
| | | |
Remove call to ConvertToWindowsExtendedPath. The call has no side effect and
the return value is discarded.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Provide a standardized way to handle the C++ "standard" headers
customized to be used with current CMake C++ standard constraints.
Offer under directory `cm` headers which can be used as direct
replacements of the standard ones. For example:
#include <cm/string_view>
can be used safely for CMake development in place of the `<string_view>`
standard header.
Fixes: #19491
|
| | |
| | |
| | |
| | |
| | | |
Reduce boilerplate necessary to create custom command lines by introducing and
applying cmMakeCommandLine and cmMakeSingleCommandLine functions.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7fe3e874d5 cmCPackLog: Fix support for multiple log message tags
74f2c0ea56 cmCTestTestHandler: Remove extra layer of parentheses
7c2767ef3b cmCTestMultiProcessHandler: Explain testRun ownership in comments
303e813438 CTest: Simplify some boolean conditions
51565abe79 cmMessageCommand: Remove extra layer of parentheses
b1cfaf7b91 cmVSSetupHelper: Remove unused SmartBSTR copy operations
3f4c4e7afe cmVSSetupHelper: Fix SmartBSTR copy operations
a8ca5aea94 cmMakefileTargetGenerator: Check for null before using a pointer
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
Acked-by: Artalus <artalus-mail@yandex.ru>
Merge-request: !3715
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In commit 0b9906c2fb (Windows: Use wide-character system APIs,
2013-12-04, v3.0.0-rc1~254^2) several buffer size computations had to be
updated to multiply by `sizeof(wchar_t)`, but for RegEnumKeyExW we were
already computing the correct number of characters with a division which
was accidentally converted to a multiplication. Use `cm::size` to
compute the number of characters in the buffer instead.
Issue: #19610
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In commit 0b9906c2fb (Windows: Use wide-character system APIs,
2013-12-04, v3.0.0-rc1~254^2) several buffer size computations had to be
updated to multiply by `sizeof(wchar_t)`, but some for RegQueryValueExW
were incorrect because the number of bytes was already computed.
Issue: #19610
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This replaces `std::ostringstream`, when it is written to only once.
If the single written argument was numeric, `std::to_string` is used instead.
Otherwise, the single written argument is used directly instead of the
`std::ostringstream::str()` invocation.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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)`
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
3b51343ea1 VS: Emit UTF-8 BOM for generated solution files
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3705
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We write UTF-8-encoded content to the `.sln` files, so tell VS to read
them as such.
Fixes: #19594
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This replaces invocations of
- `cmSystemTools::IsInternallyOn` with `cmIsInternallyOn`
- `cmSystemTools::IsNOTFOUND` with `cmIsNOTFOUND`
- `cmSystemTools::IsOn` with `cmIsOn`
- `cmSystemTools::IsOff` with `cmIsOff`
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This changes `cmMakefile::AddDefinition` to take a `cm::string_view` as value
argument instead of a `const char *`.
Benefits are:
- `std::string` can be passed to `cmMakefile::AddDefinition` directly without
the `c_str()` plus string length recomputation fallback.
- Lengths of literals passed to `cmMakefile::AddDefinition` can be computed at
compile time.
In various sources uses of `cmMakefile::AddDefinition` are adapted to avoid
`std::string::c_str` calls and the `std::string` is passed directly.
Uses of `cmMakefile::AddDefinition`, where a `nullptr` `const char*` might
be passed to `cmMakefile::AddDefinition` are extended with `nullptr` checks.
|
| | |
|
| | |
|
| | |
|
|\ \
| |/
| |
| |
| |
| |
| | |
db02be85a0 VS: Provide the default platform name to project code
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3246
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The value of `CMAKE_VS_PLATFORM_NAME` is computed by Visual Studio
generators based on `CMAKE_GENERATOR_PLATFORM` or some default.
Prior to the VS 2019 generator, the default was always `Win32`.
However, for the `Visual Studio 16 2019` generator, the default is
based on the host platform.
Store the default in a new `CMAKE_VS_PLATFORM_NAME_DEFAULT` variable for
use by project code. This is particularly useful in toolchain files
because they are allowed to set `CMAKE_GENERATOR_PLATFORM` and so
`CMAKE_VS_PLATFORM_NAME` is not yet known. Of course the toolchain file
author knows whether it will set `CMAKE_GENERATOR_PLATFORM`, and if not
then `CMAKE_VS_PLATFORM_NAME_DEFAULT` provides the platform name that
will be used.
Fixes: #19177
|