summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalVisualStudioGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* 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
| |
* | fix include order of windows.hDaniel Pfeifer2017-03-141-2/+1
|/ | | | | | Comments that indicate a special include order is necessary because GetCurrentDirectory might get redefined are outdated. Remove those outdated comments and use the normal ordering of includes.
* Refactor WINDOWS_EXPORT_ALL_SYMBOLS implementationBrad King2017-03-091-4/+8
| | | | | | | Use `cmGeneratorTarget::ModuleDefinitionInfo` to combine the implementation of `WINDOWS_EXPORT_ALL_SYMBOLS` with that of using a `.def` file as a source. Only one of these could be used within a single target before anyway.
* VS: Do not treat custom targets as CSharp targetsMichael Stürmer2017-03-071-0/+4
| | | | Fixes: #16697
* VS: Fix WINDOWS_EXPORT_ALL_SYMBOLS for external objectsZsolt Parragi2017-01-301-0/+8
| | | | | | Teach Visual Studio generators to include external object files in the list of objects whose symbols are to be exported. The Makefile and Ninja generators already did this.
* iwyu: Fix VisualStudio specific issuesDaniel Pfeifer2016-11-281-1/+3
|
* cmGlobalGenerator: Allow FindMakeProgram to failBrad King2016-10-201-1/+2
| | | | | Revise its signature to return `bool` so that it can fail and abort configuration early.
* Merge topic 'vs-csharp-prep'Brad King2016-10-201-0/+21
|\ | | | | | | | | | | f27492a4 VS: Add internal API for detecting "managed" projects 4f78b9ff VS: Add CSharp project uuid and file extension
| * VS: Add CSharp project uuid and file extensionMichael Stürmer2016-10-191-0/+21
| | | | | | | | | | This is in preparation for adding CSharp language support to the VS generator.
generated by cgit v0.12 at 2025-01-01 04:48:08 (GMT)