| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| | |
bc7c94fe MSVC: Add support for ARM64 architecture
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1215
|
| |
| |
| |
| |
| |
| | |
Visual Studio 15.4 adds support for this architecture.
Fixes: #17213
|
|\ \
| |/
|/|
| |
| |
| |
| | |
8a4755ca VS: Update support for LLVM-vs* toolsets from LLVM 5.0
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1231
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
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
|
| | |
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
5962db43 Use C++11 nullptr
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1175
|
| | | |
|
|/ /
| |
| |
| | |
Close the `<ItemGroup>` element whenever it is opened.
|
| | |
|
| | |
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
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 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
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| |/ / / /
|/| | | /
| | |_|/
| |/| |
| | | |
| | | | |
bbc1f364 VS: Fix support for nvcc flags not in our flag table
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1007
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | |
|
| | | |
|
|\ \ \
| |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | |
| | | |
51865fc6 Vs: allow CSharp targets to be linked to CXX targets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !993
|
| |/
| |
| |
| | |
Fixes: #16755
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
if /nowin32manifest is specified, it will be preferred over any occurring
/win32manifest:<file> parameter
Fixes: #16969, #16970
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
c90630c5 Vs: add support for VS_CSHARP_* target property for additional file extensions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !961
|
| | | |
| | | |
| | | |
| | | | |
Fixes: #16726
|
|\ \ \ \
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | | |
ba247cca IPO: Consider support for each language separately
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !964
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
07ec212a VS: add target property VS_DOTNET_REFERENCEPROP_<refname>_TAG_<tagname>
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !960
|
| |/
| |
| |
| | |
Fixes: #16689
|
|/
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Patch-by: vvs31415 on gitlab.kitware.com
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Fixes: #14710
|
|
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
23691d78 CUDA: Allow sources to be compiled to .ptx files
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !725
|
| |
| |
| |
| |
| | |
When the target property `CUDA_PTX_COMPILATION` is enabled CUDA OBJECT
libraries will generate ptx files instead of object files.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
fd7e8f33 VS: Fix project reference inspection in VS IDE
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !727
|