| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
Merge-request: !4297
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Extend the fix from commit 0578239d3a (VS: Tell VS 16.4 not to verify
SYMBOLIC custom command outputs, 2019-09-23, v3.15.4~2^2) to apply to
SYMBOLIC *inputs* too. This is needed when there is a chain of custom
commands that use symbolic paths for ordering.
Fixes: #20179
|
|\ \
| | |
| | |
| | | |
Merge-request: !4257
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In commit fb3370b6a1 (MSVC: Add abstraction for runtime library
selection, 2019-04-10, v3.15.0-rc1~229^2) we overlooked populating the
runtime library selection flags for the Microsoft assembler. It does
not actually have any such flags, but since its compiler id is `MSVC`
our generators expect the table to be populated. Use empty values.
Without this fix, enabling the `ASM_MASM` language with policy `CMP0091`
set to `NEW` causes an error due to the missing table entries.
Fixes: #20236, #19453
|
|\ \
| | |
| | |
| | | |
Merge-request: !4247
|
| |/
| |
| |
| |
| |
| |
| | |
VS now distributes these additional runtime libraries. Install them if
available.
Fixes: #20228
|
|\ \
| |/
|/|
| | |
Merge-request: !4191
|
|/
|
|
|
|
|
|
|
|
| |
When CUDA is enabled, and a pure non-CUDA target has
CMAKE_CUDA_SEPARABLE_COMPILATION enabled, don't actually perform
the device linking step, as it will fail. A target that has
CMAKE_CUDA_SEPARABLE_COMPILATION enabled must also have CUDA
usage (either itself, or something it links to).
Fixes: #20182
|
| |
|
|\
| |
| |
| | |
Merge-request: !4134
|
| |
| |
| |
| |
| |
| |
| |
| | |
The check added by commit 276b56f01c (FindBLAS: Add second try for
OpenBLAS with thread libraries., 2019-06-07, v3.15.0-rc2~5^2) can
work only when C or CXX is enabled.
Fixes: #20092
|
|\ \
| | |
| | |
| | | |
Merge-request: !4133
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The fix in commit 5117389931 (VS: Fix support for v142 toolset minor
versions, 2019-10-01, v3.15.5~6^2) worked around a bug in VS's placement
of toolset files. VS 16.5 will fix that bug and restore the original
pattern for locations of toolset files. Update our logic to look for
both possibilities.
Issue: #19779
|
|\ \
| | |
| | |
| | | |
Merge-request: !4122
|
| |/
| |
| |
| | |
Fixes: #20076
|
|\ \
| | |
| | |
| | | |
Merge-request: !3877
|
| | |
| | |
| | |
| | | |
Fixes: #19531
|
|\ \ \
| | | |
| | | |
| | | | |
Merge-request: !4088
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
With Clang/LLVM on MinGW, lines ending in `\r\r\n` have been observed.
Filter out all `\r` characters from these line endings.
Fixes: #20021
|
|\ \ \
| | | |
| | | |
| | | | |
Merge-request: !4008
|
| |/ / |
|
|\ \ \
| |/ /
|/| |
| | | |
Merge-request: !4007
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With the 10.x release, PostgreSQL upstream started encoding the version
as `MMmmmm` where `M` is major and `m` is minor. Prior to that, `MMmmPP`
was used where `P` was the patch number. Detect this difference and
decode it based on the used encoding.
Fixes: #19912
|
| | | |
|
| |\ \
| | | |
| | | |
| | | | |
Merge-request: !3863
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
Merge-request: !3939
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fix the `COMPILE_LANGUAGE/CXX_COMPILER_ID` variant of the example to
have the same meaning as the `COMPILE_LANG_AND_ID` variant. The
inconsistency was introduced by commit 808b818063 (Genex: CompileLang
and CompileLangAndId now match against a list of ids, 2019-05-30,
v3.15.0-rc1~11^2~1).
Fixes: #19862
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Merge-request: !3909
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
VS 2019 now distributes this additional runtime DLL with its `14.2x`
toolsets.
Fixes: #19829
|
| |/ / / / |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Merge-request: !3908
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
While the flag tables for C and C++ were generated from MSBuild `.xml`
files, the CSharp flag tables were written by hand. Copy the `v141`
flag table to use for the `v142` toolset.
Remove the special case added by commit 626c51f47b (VS: Update for
Visual Studio 2019 Preview 2, 2019-01-24, v3.14.0-rc1~74^2) that mapped
the v142 flag table lookup to v141 since we now have the real v142
table.
Fixes: #19828
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Merge-request: !3896
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Extend the fix from commit 0578239d3a (VS: Tell VS 16.4 not to verify
SYMBOLIC custom command outputs, 2019-09-23, v3.15.4~2^2) to apply to
outputs in CMake-provided targets like `install`. Simply mark these
outputs as `SYMBOLIC` too since they are not actually generated.
Fixes: #19737
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Merge-request: !3878
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The target property introduced by commit 413b71485a (Xcode: Create Xcode
schemes per target, 2019-03-11, v3.15.0-rc1~347^2) was accidentally not
initialized by `CMAKE_XCODE_GENERATE_SCHEME` for custom targets. Fix it
and update the test.
Fixes: #19759
|
|\ \ \ \ \
| |/ / / /
|/| | | |
| | | | | |
Merge-request: !3874
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When using `-T v142,version=14.22` the `.props` file location is
different starting with version `14.20` than it was in `14.16` and
below. Adapt the path based on the version.
Fixes: #19779
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
Merge-request: !3863
|
| | | | | |
|
| |\ \ \ \
| | | |/ /
| | |/| | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | |/ / / |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The "all" target in each directory is supposed to have targets from that
directory even if the directory itself is marked `EXCLUDE_FROM_ALL` in
its parent. This was broken by commit dc6888573d (Pass EXCLUDE_FROM_ALL
from directory to targets, 2019-01-15, v3.14.0-rc1~83^2) which made the
participation of a target in "all" independent of context. Revert much
of the logic change from that commit to restore the old behavior. Then
re-implement the behavior intended by the commit to keep its test
working. Extend the test to cover the old behavior too.
Fixes: #19753
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Rename the `baz` target to `subinc` to clarify that its role is to be
included even though it is in an otherwise excluded subdirectory.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Also simplify the clean step.
|
| | |/ / |
|