summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudioGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* VS: Track explicitly when platform is specified in generator nameBrad King2019-01-101-0/+1
|
* VS: Move platform name members to top-level global generatorBrad King2019-01-101-1/+28
| | | | | We no longer support any VS versions that pre-date support for multiple platforms (target architectures).
* VS: Convert WriteSLNHeader to non-virtual lookup tableBrad King2019-01-101-0/+52
|
* VS: Convert GetIDEVersion to non-virtual table lookupBrad King2019-01-101-0/+19
|
* cmake-gui: Fix "Open Project" for VS IDE with space in pathBrad King2018-10-251-2/+3
| | | | | | Do not encode the path for a shell until after we check that it exists. Fixes: #18501
* Revise C++ coding style using clang-format-6.0Kitware Robot2018-06-011-3/+3
| | | | | | | | | | | | 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.
* cmGlobalVisualStudioGenerator: remove TargetCanBeReferenced()Michael Stürmer2018-04-241-13/+0
|
* remove TargetIsCSharpOnly() and use methods from cmGeneratorTargetMichael Stürmer2018-04-231-24/+1
|
* VS: Support C# project referencesRobert Dailey2018-02-231-18/+16
| | | | | | | | | | | | When specifying a pure C# target in the `target_link_libraries()` call to another C++ target, a `<ProjectReference>` was setup for it (we wanted this) but also a corresponding `.lib` was added under `<AdditionalDependencies>` (we didn't want this). This change introduces a check that prevents `.lib` linker options from being used when the corresponding target for that library is a C# target. Fixes: #17678
* Reduce raw string pointers usage.Pavel Solodovnikov2018-01-311-1/+1
| | | | | | | | | | * Change some functions to take `std::string` instead of `const char*` in the following classes: `cmMakeFile`, `cmake`, `cmCoreTryCompile`, `cmSystemTools`, `cmState`, `cmLocalGenerator` and a few others. * Greatly reduce using of `const char*` overloads for `cmSystemTools::MakeDirectory` and `cmSystemTools::RelativePath`. * Remove many redundant `c_str()` conversions throughout the code.
* VS: Use range-based 'for' loops in generator codeVitaly Stakhovsky2017-12-211-66/+39
| | | | Use `auto` for complex types.
* server: return whether or not a target is generator providedJustin Goshi2017-11-201-2/+2
| | | | | | Some generators auto-generate targets. For example VS generators create the ALL_BUILD target. Add the ability to mark targets as generator provided and return that info through cmake-server codemodel.
* VS,Xcode: Add CMakeLists.txt sources without mutating targetsBrad King2017-10-181-9/+0
| | | | | | | | | | | | Rather than injecting `CMakeLists.txt` files into each target's `SOURCES`, teach the generators to add them during generation using dedicated code. This avoids mutating the original targets, and avoids polluting `$<TARGET_PROPERTY:foo,SOURCES>` with generator-specific content. This also avoids listing the `CMakeLists.txt` sources in the results of `CMAKE_DEBUG_TARGET_PROPERTIES==SOURCES` so the `RunCMake.TargetSources` test no longer needs a separate case for IDEs.
* cmake: Add --open option for IDE generatorsGregor Jasny2017-10-131-0/+33
|
* Replace empty-string comparisons with checking against `empty()`.Pavel Solodovnikov2017-09-211-2/+2
|
* Merge branch 'backport-vs-csharp-ref-no-asm' into vs-csharp-ref-no-asmBrad King2017-09-051-0/+13
|\
| * VS: Do not reference output assemblies if not possible for CSharp targetMichael Stürmer2017-09-051-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit v3.9.0-rc4~4^2 (Vs: allow CSharp targets to be linked to CXX targets, 2017-06-20) CSharp targets get `ProjectReference` entries to their dependencies. This causes VS to also reference the dependency's output assembly by default, which is incorrect for non-managed targets. Fix this by setting `ReferenceOutputAssembly` to `false` for targets that can't provide output assemblies. Unmanaged C++ targets (shared libs & executables) can still be referenced and a warning will be shown in the IDE but the build will not break anymore. Fixes: #17172
* | clang-format: format all code as Cpp11Daniel Pfeifer2017-08-301-2/+2
| |
* | Performance: Fix a few more unnecessary vector copies missed in af3fd6fAaron Orenstein2017-08-181-4/+8
|/
* Use quotes for non-system includesDaniel Pfeifer2017-04-111-1/+1
| | | | | | | | | | | | | Automate with: git grep -l '#include <cm_' -- Source \ | xargs sed -i 's/#include <\(cm_.*\)>/#include "\1"/g' git grep -l '#include <cmsys/' -- Source \ | xargs sed -i 's/#include <\(cmsys\/.*\)>/#include "\1"/g' git grep -l '#include <cm[A-Z]' -- Source \ | xargs sed -i 's/#include <\(cm[A-Z].*\)>/#include "\1"/g'
* VS: Simplify use of object libraries in WINDOWS_EXPORT_ALL_SYMBOLSBrad King2017-04-111-1/+0
| | | | | Object library files are already included by `GetExternalObjects` so we don't need to call `UseObjectLibraries` to get them.
* Add GENERATOR_IS_MULTI_CONFIG global propertyBastien Schatt2017-04-041-0/+1
| | | | Fixes: #16768
* VS: Decide project type by linker lang as fallbackChristian Pfeiffer2017-03-301-0/+14
| | | | Fixes: #16738
* Merge topic 'module-def-and-WINDOWS_EXPORT_ALL_SYMBOLS'Brad King2017-03-221-32/+41
|\ | | | | | | | | | | | | | | | | | | | | 075f6454 Support WINDOWS_EXPORT_ALL_SYMBOLS with `.def` files 21c4ec4f cmGlobalVisualStudioGenerator: Simplify __create_def command generation 24361a45 bindexplib: Add support for parsing and integrating `.def` files 845c4824 bindexplib: Add method for parsing and integrating `.def` files 4f90e793 bindexplib: Revise coding style of CMake-specific methods Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !581
| * Support WINDOWS_EXPORT_ALL_SYMBOLS with `.def` filesBrad King2017-03-211-29/+39
| | | | | | | | | | | | | | | | | | | | | | The `WINDOWS_EXPORT_ALL_SYMBOLS` target property exports all symbols found in object files explicitly given to the linker. However, the linker may also find additional symbols in dependencies and copy them into the linked binary (e.g. from `msvcrt.lib`). Provide a way to export an explicit list of such symbols by adding a `.def` file as a source file. Fixes: #16473
| * cmGlobalVisualStudioGenerator: Simplify __create_def command generationBrad King2017-03-211-3/+2
| |
generated by cgit v0.12 at 2025-01-09 02:26:51 (GMT)