`nvcc` from CUDA < 12.4 does support the MSVC 14.40.17.10 toolset.
Users may specify `CUDAFLAGS=-allow-unsupported-compiler` to bypass the
check. However, we do not use arbitrary user-specified flags during
compiler identification in the VS generator because escaping them for
the `AdditionalOptions` of the `.vcxproj` file requires non-trivial
logic that we currently only implement in the C++ generator code.
Instead, just always pass `-allow-unsupported-compiler` during CUDA
compiler identification in the VS generator.
Fixes: #26003
This is needed for C++ modules because `import std` support may differ
based on the standard library implementation. Extract the information as
necessary.
When cross-compiling, `clang-scan-deps` needs help to find the correct
location of core headers such as `stddef.h`. Always determine this path
and pass it when available.
Fixes: #25590
Add TIClang compiler ID and support in compiler modules. Update
documentation. Add rudimentary RunCMake test for TIClang to test
basic functionality.
Fixes: #24619
Since commit LLVM/Clang commit `5523fefb01c2` ([clang][lex] Use
preferred path separator in includer-relative lookup, 2023-09-08), part
of the upcoming 18.x release, the output format of the showIncludes flag
has changed, where it now prints paths with double backslashes:
Note: including file: .\\foo.h
Previously, we expected to see the path name in the form "./foo.h".
Extend the regex to match a path name starting with `.\`, in addition to
the existing matched patterns.
LLVMFlang 18.0 adds MSVC ABI and architecture macros. Resolve the
corresponding FIXME left by commit 26bf32cdc6 (LLVMFlang: Add support
for targeting MSVC ABI on Windows, 2023-09-28, v3.28.0-rc1~10^2).
Issue: #24840
The compiler does not yet support everything needed to integrate well
with the MSVC ABI, in particular for runtime library selection and debug
format selection. Document them in FIXME comments and leave this
support undocumented by CMake for now.
Fixes: #24840
Inspired-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Since commit d3c4c6d630 (VS: Import default C++ props file before
toolset-specific props file, 2023-03-01, v3.27.0-rc1~361^2) we import
`Microsoft.Cpp.Default.props` twice. Remove the extra import line, and
re-order imports as intended by the original change.
Since commit 8f82e755f3 (Ninja: Fix detection of MSVC showIncludes
prefix in Italian, 2023-01-26, v3.26.0-rc1~20^2) our regex no longer
matches the output from `msvc-wine`, which uses forward slashes:
Note: including file: /path/to/foo.h
`cl /showIncludes` under Wine prints paths of the form `Z:\path\to\file`,
but the `msvc-wine` wrapper converts them to the form `/path/to/file` so
that native Ninja can be used. Update our regex to match the prefix
followed by a path with a leading forward slash.
Fixes: #24908
Visual Studio 17 (Marketing name: Visual Studio 2022) still ships with
"3.0" as most recent Variant of the Android application type.
Use this revision.
Replace old-style `file(APPEND .../CMake{Output,Error}.log)` logging
with calls to `message(CONFIGURE_LOG)` to record the steps in the
`CMakeConfigureLog.yaml` configure log instead.
Issue: #23200
Generalize the fix from commit 37a279f8d1 (Ninja: Write msvc_deps_prefix
as UTF-8 when console codepage is UTF-8, 2020-07-31, v3.19.0-rc1~349^2).
`cl /showIncludes` output is encoded using the console output code page,
so this is the byte sequence that Ninja must use to match its lines.
Fixes: #24068
Instead of printing the output of the last attempt, print
the output of all attempts. This shows users that CMake isn't ignoring any provided flags ( LANG_FLAGS ).
Xcode 14 no longer accepts an empty signing identity for macOS.
However, Xcode in general does not accept an ad-hoc signing
identity for iOS. Switch based on the target platform.
Fixes: #23609
Verifying the architectures during compiler identification is redundant,
and requires a lot more up-front information than we should need.
It also causes unsupported architectures to break the compiler id and
version detection, so the resulting output from CMake does not report
the compiler version, which is useful information to know why the
specified architectures are not supported.
The "detecting compiler ABI info" and "check for working compiler" steps
already pass `CMAKE_CUDA_ARCHITECTURES` into their test projects.
Therefore we can just drop the earlier architecture testing. Bad
architectures will be reported as a not-working compiler, and the
output will include the compiler's error message.
This reverts the approach from:
* commit 19cc5bc296 (CUDA: Throw error if user-specified architectures
don't work, 2020-05-26, v3.18.0-rc1~79^2)
* commit 650c1029a0 (CUDA: Detect non-working user-specified architectures
on NVCC, 2020-05-28, v3.18.0-rc1~51^2)
* commit 01428c5560 (CUDA: Fail fast if CMAKE_CUDA_ARCHITECTURES
doesn't work during detection,
2020-08-29, v3.19.0-rc1~241^2).
Their goal was in part to avoid waiting until the test for working
compiler to detect unsupported architectures. However, experience has
shown that failing earlier is more trouble than it's worth.
Fixes: #23161
Issue: #20756
CUDA 11.6 added the `nvcc -arch=native` flag to automatically compile
for the host GPUs' architectures. Add support for specifying this
special `native` value in `CMAKE_CUDA_ARCHITECTURES` and
`CUDA_ARCHITECTURES`. During the compiler ABI detection step,
detect the native architectures so we can pass them explicitly
when using Clang or older versions of nvcc.
Fixes: #22375
Skip the architecture verification check for these values on Visual
Studio. It cannot be implemented correctly until future work delays the
check to the main compiler test step.
Issue: #23164, #23161
The logic added by commit 7808cbd644 (CMakeDetermineCompilerId: support
Intel DPC++ compiler toolset for VS gen, 2020-12-06, v3.20.0-rc1~330^2)
matches a specific toolset known to be the `icx.exe` compiler, and
assumes all other Intel C++ compilers (that are not DPC++) must be
`icl.exe`.
Since `icx.exe` is officially replacing `icl.exe`, use a regex that
matches the now-fixed set of toolsets known to use `icl.exe`. Any other
Intel C++ compiler will be assumed to be `icx.exe`.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
Changes to ``-A`` handling:
* Don't force CMAKE_GENERATOR_PLATFORM into cache when using default
value (breaks using CMake presets).
* Don't print message when using default value (breaks CMake tests).
Changes to ``GHS_PRIMARY_TARGET`` handling:
* Add as a cache variable so its known to GUI
* Don't always include``GHS_TARGET_PLATFORM``, it's only needed if
``GHS_PRIMARY_TARGET`` wasn't set by the user.
* Set ``GHS_PRIMARY_TARGET`` during platform selection instead of when
a language is enabled. By performing this sooner
``GHS_TARGET_PLATFORM`` is not always required to be set into cache.
Add fields to the VS generator to select a target framework.
Migrate the existing default for VS 12 .NET CF for Windows CE.
Report the values in `CMAKE_VS_*` variables and use them for
the CSharp compiler id project too.
Issue: #22849
Due to MCST LCC compiler identification is now changed to LCC,
there should be a way for old projects to still identify it as GNU,
as it was before.
This commits adds the policy:
CMP0129: Compiler id for MCST LCC compilers is now LCC, not GNU.
This policy controls such a behavior.
OLD behaivior is to treat LCC as GNU, NEW is to treat is as LCC.
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
Brad King