summaryrefslogtreecommitdiffstats
path: root/Source/cmVisualStudio10TargetGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* Retire std::auto_ptr and its macro CM_AUTO_PTRMatthias Maennich2017-09-251-24/+26
| | | | Signed-off-by: Matthias Maennich <matthias@maennich.net>
* Replace empty-string comparisons with checking against `empty()`.Pavel Solodovnikov2017-09-211-2/+2
|
* Merge topic 'string-clear'Brad King2017-09-191-1/+1
|\ | | | | | | | | | | | | 5db3aac1 Meta: replace empty-string assignments with `clear()`. Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !1276
| * Meta: replace empty-string assignments with `clear()`.Pavel Solodovnikov2017-09-151-1/+1
| |
* | Merge topic 'vs-manifestuac-flag-map'Brad King2017-09-191-0/+1
|\ \ | |/ |/| | | | | | | | | 3232f84c VS: Fix MANIFESTUAC link flag map to .vcxproj elements Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !526
| * VS: Fix MANIFESTUAC link flag map to .vcxproj elementscomicfans2017-09-181-0/+1
| | | | | | | | | | | | | | | | | | | | Add special parsing of the flags given in `/MANIFESTUAC:"..."` in order to map them correctly to `.vcxproj` elements. Keep the old incorrect flag table entries for `uiAccess` and `level` flags for compatibility even though they do not really exist. Fixes: #16563
* | Merge topic 'MsvcArm64'Brad King2017-09-131-0/+4
|\ \ | | | | | | | | | | | | | | | | | | bc7c94fe MSVC: Add support for ARM64 architecture Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !1215
| * | MSVC: Add support for ARM64 architectureMinmin Gong2017-09-121-0/+4
| | | | | | | | | | | | | | | | | | Visual Studio 15.4 adds support for this architecture. Fixes: #17213
* | | Merge topic 'vs-clang-llvm-support'Brad King2017-09-121-2/+1
|\ \ \ | |/ / |/| | | | | | | | | | | | | | 8a4755ca VS: Update support for LLVM-vs* toolsets from LLVM 5.0 Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !1231
| * | VS: Update support for LLVM-vs* toolsets from LLVM 5.0Konstantin Ivlev2017-09-111-2/+1
| |/ | | | | | | | | | | | | | | | | Revert commit v3.7.0-rc1~25^2 (VS: Recognize VS/LLVM toolset names as Clang, 2016-09-28). Since at least LLVM 5.0 the VS integration of the LLVM toolchain now mimics cl and accepts MSVC-style command-line arguments (unlike Microsoft Clang/C2). Fixes: #17193, #17235
* | Merge topic 'vs_improve_custom_command'Brad King2017-09-111-5/+7
|\ \ | |/ |/| | | | | | | | | | | 9ed24280 VS: only add custom command line if it is not empty 34c4108b add HasOnlyEmptyCommandLines() method to cmCustomCommandGenerator Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !1050
| * VS: only add custom command line if it is not emptyMichael Stürmer2017-09-041-5/+7
| |
* | Merge branch 'backport-vs-csharp-ref-no-asm' into vs-csharp-ref-no-asmBrad King2017-09-051-0/+7
|\ \ | |/ |/|
| * VS: Do not reference output assemblies if not possible for CSharp targetMichael Stürmer2017-09-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| |
* | Merge topic 'cxx11-nullptr'Brad King2017-08-251-1/+1
|\ \ | | | | | | | | | | | | | | | | | | 5962db43 Use C++11 nullptr Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !1175
| * | Use C++11 nullptrDaniel Pfeifer2017-08-241-1/+1
| | |
* | | VS: Fix VS_SDK_REFERENCES when target is not a Windows 10 appRoc Ramon2017-08-231-3/+3
|/ / | | | | | | Close the `<ItemGroup>` element whenever it is opened.
* | VS: remove unnecessary c_str()Vitaly Stakhovsky2017-08-171-58/+53
| |
* | VS: print comment in CSharp target only if it is actually setMichael Stürmer2017-07-121-1/+5
| |
* | Merge topic 'vs-link-debug-flags'Brad King2017-06-291-28/+9
|\ \ | |/ | | | | | | | | | | | | | | | | 7ba27e36 VS: Add v140 and v141 flag table entries for /DEBUG:NONE and /DEBUG:FULL ae44496e VS: Fix GenerateDebugInformation values for v140 and v141 toolsets 27bef160 VS: Fix GenerateDebugInformation flag map text for v141 toolsets 17a397c2 VS: Split link flag table between v140 and v141 toolsets Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !1002
| * VS: Fix GenerateDebugInformation values for v140 and v141 toolsetsBrad King2017-06-281-28/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When VS 2015 was first released, its new v140 toolset came with a `link.xml` file that changed the `GenerateDebugInformation` boolean (`false` and `true`) value from earlier toolsets to an enumeration consisting of the possible values `No`, `Debug`, and `DebugFastLink`. We first adapted to this in commit v3.4.2~2^2 (VS: Fix VS 2015 .vcxproj file value for GenerateDebugInformation, 2016-01-08), but that broke older toolsets that still expected the boolean. Then commit v3.6.0-rc1~295^2~1 (VS: Fix VS 2015 .vcxproj debug setting for older toolsets, 2016-02-24) added a hack to fix up the value based on the toolset in use. Several follow-up commits fixed this for more older toolsets because our flag table was at the time based on the generator in use rather than the toolset in use. Since commit v3.8.0-rc1~396^2 (VS: Choose flag map based on the toolset name, 2016-10-17) we use a flag table based on the toolset, so the fixup hack should not be needed. We had to keep it around only due to our default value for GenerateDebugInformation (`false` or `No`) still being based on the generator instead of the toolset. A VS 2015 update was released that changed the v140 toolset `link.xml` file back to using `false` and `true` for the `GenerateDebugInformation` enumeration variants previously known as `No` and `Debug`. In order to know which pair to use, we need to parse the `link.xml` file for the current toolset. Switch back to using `false` and `true` unconditionally in our `GenerateDebugInformation` flag table entries and default value. With that plus the toolset-based flag table, we now get incorrect values for `GenerateDebugInformation` only when using a v140 toolset from an older VS 2015 installation. Detect this case by parsing `link.xml` and add special logic to convert `false` and `true` to `No` and `Debug` to satisfy the older toolset specification. Inspired-by: Ian Hojnicki <nullref@live.com> Fixes: #17020
| * Merge branch 'vs-cuda-fix-flags' into release-3.9Brad King2017-06-271-3/+3
| |\
| * \ Merge branch 'vs-cuda-fix-flags' into release-3.9Brad King2017-06-211-10/+35
| |\ \
* | \ \ Merge topic 'vs_csharp_custom_command'Brad King2017-06-271-30/+129
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ec409a11 Vs: fix CSharp custom command by introducing inline MSBuild <Targets>s dcdab5cf Vs: factor out computation of <Link> tag for CSharp source files 0a8f469a Vs: refactor WriteCustomRule for preparation of CSharp support Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !970
| * | | | Vs: fix CSharp custom command by introducing inline MSBuild <Targets>sMichael Stürmer2017-06-221-6/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The custom command implementation is based on the Microsoft support article: https://docs.microsoft.com/en-us/visualstudio/msbuild/how-to-extend-the-visual-studio-build-process Fixes: #16960
| * | | | Vs: factor out computation of <Link> tag for CSharp source filesMichael Stürmer2017-06-221-8/+21
| | | | |
| * | | | Vs: refactor WriteCustomRule for preparation of CSharp supportMichael Stürmer2017-06-221-18/+30
| | | | |
* | | | | Merge topic 'vs-cuda-fix-flags'Brad King2017-06-271-3/+3
|\ \ \ \ \ | |/ / / / |/| | | / | | |_|/ | |/| | | | | | | | | | bbc1f364 VS: Fix support for nvcc flags not in our flag table Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !1007
| * | | VS: Fix support for nvcc flags not in our flag tableBrad King2017-06-271-3/+3
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The change in commit v3.9.0-rc4~3^2 (VS: Improve workaround for CUDA -Xcompiler placement bug, 2017-06-21) accidentally appended to the `AdditionalOptions` as if it were a `;`-separated list, but it is actually a command-line string. Append with a space instead. While at it, fix the same problem for the `AdditionalOptions` added to `CudaLink` by commit v3.9.0-rc3~1^2 (CUDA: When linking device code suppress CUDA 8.0+ deprecation warnings, 2017-06-09). Fixes: #17008
* | | Vs: disable unnecessary <ItemDefinitionGroups> for CSharp targetsMichael Stürmer2017-06-221-0/+3
| | |
* | | Vs: change comparison to use .ProjectType member always as first comparatorMichael Stürmer2017-06-221-23/+23
| | |
* | | Merge topic 'vs-cuda-fix-flags'Brad King2017-06-221-10/+35
|\ \ \ | |/ / | | | | | | | | | | | | | | | | | | 3b754215 VS: Improve workaround for CUDA -Xcompiler placement bug f2059585 VS: Fix target_compile_options for CUDA Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !996
| * | VS: Improve workaround for CUDA -Xcompiler placement bugBrad King2017-06-211-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit v3.9.0-rc1~431^2~6 (VS: Place CUDA host compiler options in proper project file fields, 2017-03-07) we worked around a bug in the CUDA VS integration by dropping `AdditionalCompilerOptions`. However, this silently drops `-Xcompiler=` options given by the user that don't map to one of CudaCompile's dedicated settings. Improve the workaround to instead put the remaining `AdditionalCompilerOptions` into the `AdditionalOptions` field behind `-Xcompiler=` ourselves.
| * | VS: Fix target_compile_options for CUDABrad King2017-06-211-7/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the VS generator to honor `COMPILE_OPTIONS` for CUDA. The exclusion added by commit v3.9.0-rc1~431^2~7 (VS: Do not pass CUDA compile options to C compiler, 2017-03-07) was correct but we need additional logic to pass the CUDA compile options to the CUDA compiler. Also we should still pass the CXX or C options to MSVC (ClCompile) when those languages are enabled even if the link language is CUDA.
* | | Merge topic 'vs_csharp_link_to_managed_cxx'Brad King2017-06-221-4/+0
|\ \ \ | | |/ | |/| | | | | | | | | | | | | 51865fc6 Vs: allow CSharp targets to be linked to CXX targets Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !993
| * | Vs: allow CSharp targets to be linked to CXX targetsMichael Stürmer2017-06-211-4/+0
| |/ | | | | | | Fixes: #16755
| * Merge branch 'ipo-per-lang' into release-3.9Brad King2017-06-141-1/+1
| |\
* | | Vs: remove /nowin32manifest from C# flags to enable default VS behaviorMichael Stürmer2017-06-161-0/+6
| | | | | | | | | | | | | | | | | | | | | if /nowin32manifest is specified, it will be preferred over any occurring /win32manifest:<file> parameter Fixes: #16969, #16970
* | | Merge topic 'vs_csharp_prop_for_all_extensions'Brad King2017-06-151-24/+44
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | c90630c5 Vs: add support for VS_CSHARP_* target property for additional file extensions Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !961
| * | | Vs: add support for VS_CSHARP_* target property for additional file extensionsMichael Stürmer2017-06-131-24/+44
| | | | | | | | | | | | | | | | Fixes: #16726
* | | | Merge topic 'ipo-per-lang'Brad King2017-06-151-1/+1
|\ \ \ \ | | |_|/ | |/| | | | | | | | | | | | | | | | | | ba247cca IPO: Consider support for each language separately Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !964
| * | | IPO: Consider support for each language separatelyBrad King2017-06-141-1/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | We only define `INTERPROCEDURAL_OPTIMIZATION` behavior for C, CXX, and Fortran languages. Do not try to enable support for other languages. Furthermore, each language builds with a different compiler, so check for support by CMake and the compiler for each language independently. Fixes: #16944
* | | Merge topic 'vs-dotnet-custom-reference-tags'Brad King2017-06-141-0/+31
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | 07ec212a VS: add target property VS_DOTNET_REFERENCEPROP_<refname>_TAG_<tagname> Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !960
| * | VS: add target property VS_DOTNET_REFERENCEPROP_<refname>_TAG_<tagname>Michael Stürmer2017-06-131-0/+31
| |/ | | | | | | Fixes: #16689
* | CUDA: When linking device code suppress CUDA 8.0+ deprecation warningsRobert Maynard2017-06-131-0/+7
|/ | | | | | The CUDA compiler automatic deprecation warnings are pure noise when doing device linking, and should be suppressed to reduce the amount of confusion from users.
* cmVisualStudio10TargetGenerator: Remove shadowing local variableBrad King2017-05-301-2/+0
|
* VS: Fix indentation of .vcxproj filesBrad King2017-05-241-12/+12
| | | | Patch-by: vvs31415 on gitlab.kitware.com
* VS: Write UseOfMfc tag only if CMAKE_MFC_FLAG is presentBrad King2017-05-221-10/+12
| | | | | | | Don't bother writing `UseOfMfc` to `.vcxproj` files when the value is just the default of `0`. This keeps the files cleaner. Patch-by: vvs31415 on gitlab.kitware.com
* VS: Fix .vcxproj ProjectGuid element caseBrad King2017-05-091-2/+2
| | | | | | | | The `.vcxproj` file format expects `ProjectGuid`, not `ProjectGUID`. The latter is expected by `.vcproj` files from VS 2008, so this was likely a typo when the VS 2010 generator was first introduced. Fixes: #11968
generated by cgit v0.12 at 2025-01-17 04:16:50 (GMT)