Add a platform module for using clang for HIP on windows, based on the
CXX module.
HIP language on windows works without this, but mixing with MSVC
produces catastrofical results.
Add the same restriction with HIP as C and C++ had prior:
Either none are compiled with MSVC or all are.
clang-cl support for HIP does not work yet: it needs more work in both
hip-lang-config.cmake and cmake itself.
Replace our hard-coded default for `/Zi` with a first-class abstraction
to select the debug information format an enumeration of logical
names. We've long hesitated to do this because the idea of "debug
information format" touches on related concepts on several platforms.
Avoid that scope creep by simply defining an abstraction that applies
only when targeting the MSVC ABI on Windows.
Removing the old default flag requires a policy because existing
projects may rely on string processing to edit them and choose a
runtime library under the old behavior. Add policy CMP0141 to
provide compatibility.
Fixes: #10189
Since commit bb61c2d024 (Clang: use -imsvc for system include dirs when
running on Windows, 2020-09-16, v3.19.0-rc1~162^2) we use the `-imsvc`
flag followed by the include directory as a separate argument. Some
versions of `clang-tidy` do not support the flag unless the include
directory is attached to it, so use that form instead.
A similar fix was made by commit 3a8b6653dc (MSVC: Use -external:I flag
without space to support Clang tools, 2022-01-11, v3.22.2~8^2).
Fixes: #23517
Add `COMPILE_WARNING_AS_ERROR` target property and supporting
`CMAKE_COMPILE_WARNING_AS_ERROR` variable.
`COMPILE_WARNING_AS_ERROR` is initialized by
`CMAKE_COMPILE_WARNING_AS_ERROR`. It is a boolean variable. If it is
true, it expands to a different flag depending on the compiler such that
any warnings at compile will be treated as errors.
Supports compiler ids that I could find a relevant flag for.
Update the archive rules added by commit 6e3655db2c (Clang: add LTO
support for GNU-command line clang on windows, 2019-07-08,
v3.16.0-rc1~161^2~3) to match the `ar` convention we use for normal
archives.
Issue: #21988
Allows using different compilers with different flags for different languages.
For example Clang with GNU-like commandline for CXX and MSVC as host compiler
for CUDA.
Should help with #21914.
In commit bb61c2d024 (Clang: use -imsvc for system include dirs when
running on Windows, 2020-09-16, v3.19.0-rc1~162^2) we added `-imsvc`
for all Clang compilers targeting the MSVC ABI. However, the option
only exists for the MSVC-like front-end. The GNU-like front-ends
use `-isystem`.
Fixes: #21789
When preprocessing the rc file using the clang gnu front end we need to
force the source file type to a c file for the preprocessing to take
place.
Fixes: #21472
These changes are in preparation of compiler generated dependencies support
for Makefiles generators
* compiler output and dependency target can be different for Makefiles generators
* resolve inconsistency naming for dependency file place-holder
On Linux and macOS, absolute paths start with `/` which may be
interpreted by clang-cl as an option. To avoid this, we separate the
source file path from preceding options with `--` to tell `clang-cl` it
is not an option.
Since commit 1c2d031cbd (Add -E cmake_llvm_rc to preprocess files for
llvm-rc, 2020-01-14, v3.17.0-rc1~24^2) with llvm-rc we explicitly
preprocess RC source files and then compile separately without -I flags.
This broke cases where the RC source references data files adjacent to
itself or in the include path.
This change adds the expansion of the include paths when calling the
llvm-rc in order for the resource files to be picked up correctly by
llvm-rc. Since the RC compiled file is first preprocessed, the file
being compiled by llvm-rc resides in the build directory. In order for
llvm-rc to find the resource data specified relative to the .rc file
being compiled, the source file path is preppended in the include list
so that the original source path takes priority over all the other
includes paths specified.
A space was added in the CMAKE_INCLUDE_FLAG_RC to make the include
directive work properly for llvm-rc. Checks on the rc.exe showed that
the syntax change doesn't affect it's proper operation.
Fixes: #20529
2c724c3aea llvm-rc: Write depfile to location specified by the generator
4cc876540e llvm-rc: Select preprocessor from active languages
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4524
Move the depfile flags to `CMAKE_DEPFILE_FLAGS_RC` so that they
are only usedwith generators that use depfiles. Also switch to
using the `<DEPFILE>` placeholder for the location of the depfile
so that it goes where the generator expects.
Fixes: #20493
The llvm-rc preprocessor is selected according to the
CMAKE_C_COMPILER_ID / CMAKE_CXX_COMPILER_ID which are only defined when
the C or CXX language is active.
Since commit 1c2d031cbd (Add -E cmake_llvm_rc to preprocess files for
llvm-rc, 2020-01-14, v3.17.0-rc1~24^2) we pass the full target `<FLAGS>`
to the llvm-rc resource compiler, but we should pass only `<DEFINES>`.
Fixes: #20414
Add an additional include flag to PCH usage command line to fix programs
that rely on `compile_commands.json` file. Pass it to the preprocessor
directly to avoid compiler driver to change it to '-include-pch'.
When preprocessor is requested to preprocess a file, it tries to get
the original filename from '.pch' and uses that file for preprocessing.
CMake generates a '.pch' file from the '.hxx' file by passing an empty
'.cxx' source file to the compiler as a compilation unit and the header
file with the '-include' flag. After that, compiler puts compilation
unit filename in the '.pch' as the original filename.
However, CMake build system uses empty file as the source file and
passes the header file using '-include-pch' flag. As a result, Clang
uses the wrong file for preprocessing and produces the corrupted
preprocessed file.
Fixes: #20355
Signed-off-by: Sergey Larin <cerg2010cerg2010@mail.ru>
llvm-rc requires preprocessed rc files. The CMake command line tool
cmake_llvm_rc enables channing the preprocessor call and the resource
compiler and make this appear as single compilation step.
When llvm-rc is detected as resource compiler, the RC compilation step
is set to use this command.
This allows building .s/.S assembly code, and makes sure that the
`-fPIC` option isn't passed to the compiler (as it errors out on
Clang and causes a loud warning on GCC).
Modern distributions of packages built with MinGW tools provide `.dll.a`
import libraries. Prefer those instead of finding plain `.dll` files.
This avoids accidentally finding unrelated Windows `.dll` files.
Fixes: #20019
dca9c33abc Tests: Remove old IPO test
c856d4556b bindexplib: supporting llvm bitcode formats using llvm-nm
079b8e2916 Clang: prefer lld-link over link.exe
6e3655db2c Clang: add LTO support for GNU-command line clang on windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3527
This change modifies how CMAKE_RC_COMPILER is configured to improve
the out-of-box experience for developers using Clang on Windows.
The previous behavior was to require the user to explicitly specify
the resource compiler when CMake was called. The new behavior
is to automatically attempt to locate the MSVC rc binary and use that
if it's found. If rc is not available, CMake will now fall back to
Clang's llvm-rc binary.
With this change in place, trivial C/C++ programs can be generated
with Ninja and Clang on Windows without running into errors about
a missing resource compiler.
Fixes: #19318
