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
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
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
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
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.
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.
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
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.
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
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
If a static library has the property CUDA_RESOLVE_DEVICE_SYMBOLS enabled
it will now perform the device link step. The normal behavior is
to delay calling device link until the static library is consumed by
a shared library or an executable.
The braces around project reference GUIDs for vcxproj projects were
apparently optional in the past, but Visual Studio 2017 is more strict,
displaying a warning, and not displaying project reference properties
unless the braces are present.
Fixes: #16820
Add internal infrastructure for looping over all sources for all
configurations and generating each source with exclusion marks
for configurations in which they do not participate. This does
not yet make per-config sources available in general but does
set up some of the needed infrastructure.
Unfortunately doing this cleanly will require major refactoring of both
the VS 7-9 generators and the VS 10+ generators (for separate reasons).
Instead add some extra internal structures to carry information where we
need it.
1d829c86 Use quotes for non-system includes
26ee9e42 CPack: drop CPack prefix for includes
5afac50f cmConfigure: Ensure separate include block in headers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !691
Object library files are already included by `GetExternalObjects`
and `GetConfigCommonSourceFiles` so we don't need to call
`UseObjectLibraries` to get them.
dfa8263f Implement interprocedural optimization for GNU compilers
1588a577 Add policy CMP0069 to enforce INTERPROCEDURAL_OPTIMIZATION
a7575700 Refactoring: s,GetFeatureAsBool,IsIPOEnabled,
e05835c3 CheckIPOSupported: Visual Studio and Xcode generators do not support IPO
Acked-by: Kitware Robot <kwrobot@kitware.com>
Reviewed-by: Brad King <brad.king@kitware.com>
Reviewed-by: Nils Gladitz <nilsgladitz@gmail.com>
Merge-request: !568
Previously the `INTERPROCEDURAL_OPTIMIZATION` target property was
honored only for the Intel compiler on Linux and otherwise ignored. In
order to add support for more compilers incrementally without changing
behavior in the future, add a new policy whose NEW behavior enforces the
`INTERPROCEDURAL_OPTIMIZATION` property. Add flags for supported
compilers and otherwise produce an error.
