| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| | |
f3d7a15010 VS: Fix ClangCL toolset compiler path detection
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4523
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Prior to commit 3c125c6de0 (VS: Support Visual Studio Clang Toolkit
identification, 2019-12-03, v3.17.0-rc1~341^2) using `-T ClangCL`
would work but `CMAKE_{C,CXX}_COMPILER` would be detected as `cl.exe`
even though `clang-cl.exe` is the actual compiler. That commit
attempted to fix the detection by using `$(ClangClExecutable)`
as we do for LLVM-distributed toolsets, but that is not actually
defined. Instead, look for `$(CLToolExe)` in the `PATH`.
Fixes: #20504
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6c7e6b1e49 Ninja Multi-Config: Fix MSVC showincludes prefix detection
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kyle Edwards <kyle.edwards@kitware.com>
Merge-request: !4526
|
| |/
| |
| |
| |
| |
| | |
Activate the detection logic for this generator too.
Fixes: #20506
|
| |
| |
| |
| |
| |
| | |
For example, with GNU `as`, we match `GNU assembler`, but with GNU `gcc`
as the assembler, we do not match anything. Distinguishing these cases
may be useful for constructing assembler command lines.
|
|/
|
|
|
|
| |
Apply the change from commit d751d2d2ed (CMakeDetermineCompilerABI: set
locale to C for try_compile(), 2019-01-14, v3.14.0-rc1~108^2~1) to the
`CMAKE_DETERMINE_COMPILER_ID_VENDOR` implementation too.
|
|
|
|
|
|
| |
Fixes #18733
Correct an oversight where the MSVC generators didn't populate
CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES.
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
2f853eec3d Merge branch 'backport-3.15-vs-v142-version' into backport-3.16-vs-v142-version
d8d4924d98 VS: Fix support for v142 toolset minor versions in VS 16.5+
07612646fe VS: Fix support for v142 toolset minor versions in VS 16.5+
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4133
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The fix in commit 5117389931 (VS: Fix support for v142 toolset minor
versions, 2019-10-01, v3.16.0-rc1~32^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
|
| |
| |
| |
| |
| | |
Teach CMake that the `ClangCl` toolset uses the `ClangClExecutable`
value as the path to the compiler executable.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Ninja generator's support for Fortran requires that source files
be preprocessed explicitly first. However, the `xlf` compiler does
not have a simple `-E` option or equivalent to do preprocessing.
The only documented way to get preprocessed output is to use `-d`
to leave it behind, but only at an inflexible location.
Instead, create our own `cpp` wrapper script and substitute it for the
real preprocessor using `-tF -B ...`. Teach the wrapper to map the
`cpp` output to the location we need and then invoke the real `cpp`
underneath.
Fixes: #19450
|
| |
| |
| |
| | |
Issue: #19708
|
|/
|
|
| |
Fixes: #19708
|
|\
| |
| |
| |
| |
| |
| | |
5117389931 VS: Fix support for v142 toolset minor versions
Acked-by: Kitware Robot <kwrobot@kitware.com>
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
|
| | |
|
|\ \
| |/
| |
| |
| |
| |
| | |
863f7eb6d7 clang: Restore support for clang-cl on non-Windows hosts
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3634
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The frontend variant detection logic added by commit 53fbe23f3f (clang:
introduce CMAKE_<lang>_COMPILER_FRONTEND_VARIANT, 2019-02-20,
v3.15.0-rc1~41^2~8) assumes that `clang-cl` only runs on a Windows host.
It is also available on non-Windows hosts. Fix the condition.
Fixes: #19544
|
|/
|
|
|
|
|
|
|
|
|
| |
Our compiler identification source encodes `INFO:compiler[...]` and
similar strings in compiled objects or binaries that we then extract to
get information about the compiler. With most compilers the strings are
encoded in the binaries as a simple byte sequence. However, some
compilers use other encodings. For example, the MS CSharp compiler uses
UTF-16LE and a TI compiler uses UTF-16BE. Try each encoding.
Fixes: #19459
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
74829f01b1 Help: Add notes for topic 'clang-gnulike-support'
19669abe1d Tests: handle string escaping differences with NMake+clang
a2a90f41e3 Tests: require C++14 for the Tutorial
4819ff9647 Tests: fix failures with gnu mode clang on windows
26af0b25e7 cmake: use correct stack size with gnu mode clang on windows
d44c0db0b2 clang: setup correct configuration in gnu mode
b7d5ef23e9 cmGlobalNinjaGenerator: use gnu compatible paths with clang in gnu mode
3d0210d8dc binutils: add the llvm-* variants to the tool lists.
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Francesco Bertolaccini <francesco@bertolaccini.dev>
Acked-by: Stanislav Ershov <digital.stream.of.mind@gmail.com>
Acked-by: Saleem Abdulrasool <compnerd@compnerd.org>
Merge-request: !2992
|
| |
| |
| |
| |
| |
| |
| |
| | |
This variable is set to GNU on Windows when clang.exe ar clang++.exe is
used, and set to MSVC for clang-cl.exe.
CMAKE_<lang>_SIMULATE_ID is set to MSVC in both cases, as clang defaults
to -fms-compatibility for all command lines on windows.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
9c07cefee5 VS: Fix ApplicationTypeRevision in builtin check projects
639e14def6 VS: Factor out helper to compute ApplicationTypeRevision
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3350
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Do not use the entire `CMAKE_SYSTEM_VERSION`, but rather the first two
components only.
Fixes: #19275
|
|/ /
| |
| |
| |
| |
| |
| | |
The compiler identification message was modified in commit ea83d0f8fb
(IAR: Generalize and add support for IAR RX compiler, 2019-04-05) to
include the architecture id since IAR compilers are arch-specific.
Revise the logic to avoid modifying the message for other compilers.
|
| | |
|
| |
| |
| |
| |
| | |
If compiler id detection gave us the compiler tool, copy its value to
the `CMAKE_${lang}_COMPILER` variable as early as possible.
|
|/
|
|
| |
Fixes: #18215
|
|
|
|
|
|
|
|
|
|
| |
Supports versioned LLVM toolsets like LLVM_v142, LLVM_v141,
LLVM_v141_xp, etc. for Visual Studio (2010 and later).
The name for versioned LLVM toolsets has "LLVM_" prefix
plus MSVC toolset name (i.e. v142, v141, v141_xp, etc.).
Fixes: #19203
|
|
|
|
| |
Moved common ASM setup to the common macros and changed version check.
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
8375c303e2 VS: Fix detection of clang-cl with -T llvm
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3024
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When using a VS generator with `-T llvm`, MSBuild relies on the "LLVM
Compiler Toolchain" VS Extension. This does not put `clang-cl` in the
`PATH` inside the build, and LLVM no longer provides a `cl` replacement
either. Therefore we need another way to extract the path to the
`CMAKE_{C,CXX}_COMPILER`. Fortunately the LLVM VS integration provides
a `$(ClangClExecutable)` macro we can reference to get the path.
Fixes: #18983
|
|/
|
|
|
|
|
|
| |
MS-style command-line tools accept either `/` or `-` for command-line
options. Prefer `-` over `/` so that non-MS tools do not treat it as a
path.
Fixes: #18941
|
|
|
|
| |
Closes: #18396
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
e8ee8cab97 Xcode: Completely disable code signing for compiler id detection
11da882a12 Apple: Introduce separate system name for iOS, tvOS, and watchOS
36cf44a7a3 Tests: Isolate RunCMake.XcodeProject per-device cases from host arch
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2392
|
| |
| |
| |
| | |
Issue: #17870
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Remove code signing requirements for non-macOS
- Do not set deployment target for non-macOS
- Build static library for compiler feature detection for non-macOS
- Use framework to run CompilerId tests for watchOS
- Port tests to new SDK handling
- Add new Apple cross-compiling section to toolchain documentation
Closes: #17870
|
|/
|
|
|
|
| |
Xcode 10.2 no longer supports Swift language versions before 4.0.
Fixes: #18871
|
|
|
|
|
|
|
|
|
|
|
|
| |
-- Detect GHS compiler and version
Detect ARCHITECTURE_ID for PPC / ARM / 86 targets
Detect PLATFORM_ID for Integrity and Integrity178 platforms
Using defines specified in the documents for the compilers: 201416 PPC / 201754 ARM / 201714 86
-- Fallback C/CXX compiler ID to GHS if not otherwise detected and using GHS MULTI generator
Works around issue with some GHS compilers not setting __ghs__ compiler define
-- Tweak Compiler ID checking so major id of 002017 is not replaced with 217
-- Prefer try_compile() library targets when testing for working GHS compilers
-- Avoid CMake errors if reading past end of file for checking if file is PE executable
|
|
|
|
|
|
|
| |
Teach `CMakeDetermineCompilerId` to recognize and parse the IAR-AVR
binary format so we can recognize this compiler id.
Issue: #18557
|
|
|
|
|
|
|
| |
Code for this was prototyped when ELF detection was added long ago but
left commented out. Use either MH_MAGIC or MH_CIGAM for the 32-bit
variant and use either or MH_MAGIC_64 or MH_CIGAM_64 for the 64-bit
variant.
|
|
|
|
|
|
|
|
| |
The IAR 6.50.6 compiler places extra/truncated copies of the
compiler id `INFO:` strings into binaries with a prefix like
`?<Constant "`. Teach CMakeDetermineCompilerId to ignore them.
Fixes: #18333
|
|
|
|
|
|
|
| |
If `CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY` is set then propagate
it to the compiler id test project too.
Fixes: #18292
|
|
|
|
|
|
|
|
|
| |
Xcode 10 no longer populates `CURRENT_ARCH` with the current
architecture in shell scripts and instead uses `undefined_arch`.
Instead we must use `ARCHS`. It lists all architectures separated by
spaces.
Fixes: #18085
|
|
|
|
|
|
|
|
| |
Add new `version=` parameter in the toolset setting to select the
version. Add variable `CMAKE_VS_PLATFORM_TOOLSET_VERSION` to hold the
version, if one is set (blank indicates default).
Fixes: #17549
|
|
|
|
|
|
|
| |
If the CUDA version macros are not defined, run `nvcc --version` and
extract the version from its output.
Fixes: #17920
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The check added by commit v3.10.0-rc2~2^2 (Clang: Diagnose unsupported
GNU-like clang targeting MSVC ABI, 2017-10-10) is incorrectly detecting
clang-cl 6.0 as GNU-like. Currently cmake is testing if the clang
compiler accepts `--version` to see if it accepts GNU style flags.
However, with the latest llvm snapshot this also works for clang-cl:
> clang-cl --version
clang version 6.0.0 (trunk)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
So instead we should use the `/?` flag which fails with clang but
works with clang-cl:
> clang-cl /? &> /dev/null; echo $?
0
> clang /? &> /dev/null; echo $?
1
Fixes: #17518
|
|
|
|
|
|
|
|
|
|
| |
The LLVM/Clang installer on Windows provides a `LLVM/bin` directory
containing `clang.exe` and `clang++.exe` command-line tools that have a
GNU-like command-line but target the MSVC ABI (instead of MinGW). We
do not support this combination, so diagnose and reject it explicitly.
Tell users what to do to use the `clang-cl.exe` tool instead.
Issue: #16439
|
|
|
|
|
|
|
|
|
|
|
| |
Create a `CMAKE_<LANG>_COMPILER_VERSION_INTERNAL` variable to hold
a secondary/internal compiler version number detected at the same
time as the primary compiler version. This will be useful for some
compilers where we need such a number to determine correct usage.
Inspired-by: Stefan Andersson <tfosm@hotmail.com>
Suggested-by: Norbert Lange <norbert.lange@andritz.com>
Issue: #17264
|
|
|
|
| |
Closes #16839
|