summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudioGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* Merge topic 'vs-sln-version-16'Brad King2020-06-031-1/+1
|\ | | | | | | | | | | | | b69010b719 VS: Fix .sln support for VS Version Selector with VS 2019 Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4844
| * VS: Fix .sln support for VS Version Selector with VS 2019Brad King2020-06-021-1/+1
| | | | | | | | | | | | VS 2019 changed the naming pattern used by 2015 and 2017. Fixes: #20783
| * Merge topic 'vs-sln-version' into release-3.17Brad King2020-05-201-0/+1
| |\ | | | | | | | | | | | | | | | | | | 88ad02f1ec VS: Restore .sln support for VS Version Selector Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4765
* | \ Merge topic 'vs-sln-version'Brad King2020-05-201-0/+1
|\ \ \ | | |/ | |/| | | | | | | | | | | | | 88ad02f1ec VS: Restore .sln support for VS Version Selector Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4765
| * | VS: Restore .sln support for VS Version SelectorBrad King2020-05-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* | | cmGeneratorTarget::GetProperty: return cmPropVitaly Stakhovsky2020-04-291-3/+3
| | |
* | | Add support to indicate UTF-8 custom command pipe output encodingJustin Goshi2020-04-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | cmMakefile::GetProperty: return cmPropVitaly Stakhovsky2020-04-011-3/+3
| |/ |/|
* | Ninja Multi-Config: Fix issue with framework dependencies and AutogenKyle Edwards2020-02-171-1/+1
| | | | | | | | Fixes: #20345
* | Source: use std::string in place of const char*Vitaly Stakhovsky2020-01-291-3/+3
| |
* | cmMakefile: Delay custom command creationDaniel Eiband2019-11-241-3/+3
| | | | | | | | | | | | | | | | 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
* | cmCustomCommand: Explicitly pass backtrace on constructionDaniel Eiband2019-11-241-3/+4
| |
* | cmLocalGenerator: modernize memory managementMarc Chevrier2019-11-111-6/+7
| |
* | VS: Add support for per-config sourcesBrad King2019-10-171-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Teach check for single-language targets to consider all configurationsBrad King2019-10-171-2/+1
|/
* Revise include order using clang-format-6.0Kitware Robot2019-10-011-3/+6
| | | | | 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.
* Merge branch 'backport-3.15-fix-EXCLUDE_FROM_ALL-subdir-all'Brad King2019-09-301-1/+1
|\ | | | | | | | | | | | | | | 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`.
| * Merge branch 'backport-3.14-fix-EXCLUDE_FROM_ALL-subdir-all'Brad King2019-09-301-1/+1
| |\
| | * Restore "all" target in subdirectories marked EXCLUDE_FROM_ALLBrad King2019-09-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | cmMakefile: Remove AddUtilityCommand overload without byproductsDaniel Eiband2019-09-261-2/+3
| | |
* | | cmMakefile: Move enumerations into new headerDaniel Eiband2019-09-261-1/+1
| | | | | | | | | | | | The enumerations will also be used in cmLocalGenerator.
* | | Merge topic 'fix-vsmacro-access-violation'Brad King2019-09-261-13/+3
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | 7847fef510 VS: Fix access violation when calling Visual Studio macro Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3853
| * | | VS: Fix access violation when calling Visual Studio macroDaniel Eiband2019-09-241-13/+3
| | | | | | | | | | | | | | | | Fixes: #19730
* | | | VS: Remove call to ConvertToWindowsExtendedPath with result discardedDaniel Eiband2019-09-211-1/+0
|/ / / | | | | | | | | | | | | Remove call to ConvertToWindowsExtendedPath. The call has no side effect and the return value is discarded.
* | | cmstd: Modernize CMake system headersMarc Chevrier2019-09-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | cmCustomCommandLine: Provide command line make functionsDaniel Eiband2019-09-161-8/+3
| | | | | | | | | | | | | | | Reduce boilerplate necessary to create custom command lines by introducing and applying cmMakeCommandLine and cmMakeSingleCommandLine functions.
* | | Merge topic 'pvs-cleanup'Brad King2019-08-261-9/+8
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | cmGlobalVisualStudioGenerator: Fix buffer sizes used with RegEnumKeyExWBrad King2019-08-221-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | cmGlobalVisualStudioGenerator: Fix buffer sizes used RegQueryValueExWBrad King2019-08-221-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | Source sweep: Replace std::ostringstream when used with a single appendSebastian Holtermann2019-08-231-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | Source sweep: Use cmStrCat for string concatenationSebastian Holtermann2019-08-221-8/+7
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)`
* | | Merge topic 'vs-sln-bom'Brad King2019-08-211-0/+3
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | 3b51343ea1 VS: Emit UTF-8 BOM for generated solution files Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3705
| * | | VS: Emit UTF-8 BOM for generated solution filesJustin Goshi2019-08-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We write UTF-8-encoded content to the `.sln` files, so tell VS to read them as such. Fixes: #19594
* | | | Source sweep: Use cmIsOn instead of cmSystemTools::IsOnSebastian Holtermann2019-08-171-1/+1
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | This replaces invocations of - `cmSystemTools::IsInternallyOn` with `cmIsInternallyOn` - `cmSystemTools::IsNOTFOUND` with `cmIsNOTFOUND` - `cmSystemTools::IsOn` with `cmIsOn` - `cmSystemTools::IsOff` with `cmIsOff`
* | | cmMakefile: Let AddDefinition accept a value as cm::string_viewSebastian Holtermann2019-07-241-3/+3
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | cmGlobalVisualStudioGenerator: remove redundant variablesLeonid Pospelov2019-04-241-12/+5
| |
* | cmGlobalVisualStudioGenerator: use cmJoin to join the filenamesLeonid Pospelov2019-04-221-11/+1
| |
* | cmGlobalVisualStudioGenerator: use auto instead of iterator typesLeonid Pospelov2019-04-221-6/+5
| |
* | Merge topic 'vs-default-platform'Brad King2019-04-221-0/+8
|\ \ | |/ | | | | | | | | | | db02be85a0 VS: Provide the default platform name to project code Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3246
| * VS: Provide the default platform name to project codeBrad King2019-04-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | cmTarget: Move member `*Commands` to implSebastian Holtermann2019-03-231-0/+1
| |
* | Merge topic 'vs-fortran-rc'Brad King2019-03-041-0/+4
|\ \ | |/ | | | | | | | | | | 0b82f56ac6 VS: Fix Fortran target type selection with RC sources Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3050
| * VS: Fix Fortran target type selection with RC sourcesBrad King2019-03-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | The Intel Fortran `.vfproj` files do support both Fortran and the Windows Resource compiler (`.rc)` files. Prior to CMake 3.9 we did not support that, but commit 2c9f35789d (VS: Decide project type by linker lang as fallback, 2017-03-30, v3.9.0-rc1~340^2) accidentally enabled it. It was then broken by commit d3d2c3cd49 (VS: Fix Fortran target type selection when linking C++ targets, 2019-02-04, v3.14.0-rc1~13^2). Restore support for Fortran+RC in VS projects and add a test case. Fixes: #19002
* | cmSystemTools::Error: consolidate parameters into single std::stringVitaly Stakhovsky2019-02-201-1/+1
|/
* VS: Fix Fortran target type selection when linking C++ targetsBrad King2019-02-041-19/+12
| | | | | | | | | | | | | | Since commit 2c9f35789d (VS: Decide project type by linker lang as fallback, 2017-03-30, v3.9.0-rc1~340^2) we consider the linker language when detecting whether to generate a `.vfproj` or `.vcxproj` file. However, this could cause C-only projects to become `.vfproj` files if they link to Fortran projects. Instead we should consider only the `LINKER_LANGUAGE` property on the target itself. This approach is already used for CSharp. It allows project code to specify the project file type for a target with no sources but does not allow linked targets to affect it. Fixes: #18687
* cmSystemTools: copy file member functions accept std::string paramsVitaly Stakhovsky2019-01-291-3/+2
| | | | | Cleaned up `c_str()`s. `cmSystemTools::CopyFileIfDifferent()` removed as redundant.
* cmSystemTools::Message: Add overload accepting std::stringVitaly Stakhovsky2019-01-281-2/+2
|
* Pass EXCLUDE_FROM_ALL from directory to targetsZack Galbreath2019-01-211-1/+1
| | | | | | When a target is created it now inherits the EXCLUDE_FROM_ALL property from its directory. This change makes it possible to include a target in "all", even if its directory has been marked as EXCLUDE_FROM_ALL.
* Factor out enum MessageType into dedicated headerBruno Manganelli2019-01-161-1/+2
| | | | Reduce the number of files relying on `cmake.h`.
* VS: Add Visual Studio 16 2019 generatorBrad King2019-01-111-0/+11
| | | | | | | | | | | | Add this generator *without* support for specifying the target architecture in the generator name. cmake-gui will be taught to provide a field for this, and command-line builds can use -A. Also, teach this generator to select a default target architecture based on the host architecture. Fixes: #18689 Inspired-by: Egor Pugin <egor.pugin@gmail.com>
generated by cgit v0.12 at 2024-12-29 11:36:35 (GMT)