__compiler_clang() doesn't call __compiler_gnu() if we're emulating MSVC. Thus
CMAKE_DEPFILE_FLAGS_CUDA remains unset and compiling doesn't work, due to NVCC
dependency injection workaround in CMakeCUDAInformation.cmake, which triggers
for Ninja if they're not set.
Always set the depfile flags to fix this. Most other compiler modules seem to
do the same.
allows cmake to fall back to CMAKE_SYSTEM_ARCH in case CMAKE_SYSTEM_PROCESSOR is not in armclang -mcpu=list
additionally checks if CMAKE_SYSTEM_PROCESSOR belongs to armlink --cpu=list
Fixes: #19962
The PCH settings are shared by C and CXX languages but do not make sense
for Fortran. In particular, `CMAKE_PCH_EXTENSION` should not be set
because it can overwrite the value set for C/C++ languages, which may
have a different compiler vendor than the Fortran compiler.
Fixes: #20752
GitLab now uses a `/-/` component between the `group/project` part of
the URL and the `{issues,merge_requests,tree}` part so that it can
support `group/subgroup/project` with arbitrary depth.
Since commit 0d0145138f (CUDA: Add abstraction for cuda runtime
selection, 2019-11-29, v3.17.0-rc1~83^2) we add CUDA runtime library
selection flags by default.
To maintain backwards compatibility the default CUDA runtime
library needs to be computed based on what libraries are found
on the initial compiler invocation. For example a toolchain
could establish initial flags that have all CUDA compilations
using the runtime version, and if we don't detect this we will
try to link to both the static and shared runtime.
Co-Author: Brad King <brad.king@kitware.com>
Fixes: #20708
When crosscompiling we pass the sysroot.
We need to try various architecture flags. Clang doesn't automatically
select one that works. First try the ones that are more likely to work
for modern installations:
* <=sm_50 is deprecated since CUDA 10.2, try sm_52 first for
future compatibility.
* <=sm_20 is removed since CUDA 9.0, try sm_30.
Otherwise fallback to Clang's current default. Currently that's `sm_20`,
the lowest it supports.
Separable compilation isn't supported yet.
Fixes: #16586
65c1320719 Compiler/TI: Fix C++ toolchain command-lines
4110d9dffb Compiler/TI: Fix linker command line for C++
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4627
properties LINK_OPTIONS and INTERFACE_LINK_OPTIONS are propagated
to the device link step.
To control which options are selected for normal link and device link steps,
the $<DEVICE_LINK> and $<HOST_LINK> generator expressions can be used.
Fixes: #18265
These standard flags are the same for CXX, OBJCXX and CUDA.
Refactor them into a single macro to reduce duplication and so we can easily reuse them.
Updated bootstrap script to search in the general Clang module instead of the language-specific.
46d9006efa XL: Add comment clarifying why we pretend it has full C++11/14 support
4aaa9ea96c XL: C++14 language level flags are only available on Linux
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4551
Since commit b0f46c48f6 (CompileFeatures: Now able to presume full
language level support, 2019-03-06, v3.15.0-rc1~265^2~1) we pretend that
the XL compiler has full C++11 and C++14 support so that projects
specifying granular features will at least get the corresponding
compiler mode. This is a work around for our lack of a full feature
check table for this compiler that works in common cases. Add a comment
explaining this.
Issue: #20521
Since commit 458ea9d76c (XL: Add C++14 language level flags, 2019-04-15,
v3.15.0-rc1~226^2) we use `-qlanglvl=extended1y` for C++14 with XL 16.1.
However, that flag is only supported on a Linux host.
Issue: #20521
9728839b9e ASM: Fix executable link lines with GNU 'as' tool as CMAKE_ASM_COMPILER
5932f0be4f ASM: Fix depfile flags for GNU 'as' tool
0d0aa98c84 ASM: Record vendor-specific output matched to identify assembler
ee3ec27465 CMakeDetermineCompilerId: Set locale to C for vendor output match
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4460
The GNU `as --help` shows `--MD <file>` as an option to generate depfiles
as needed by Ninja. There is no `-MT <target>` flag but fortunately the
generated files automatically account for the `-o <obj>` flag.
Issue: #20426
The XL Fortran compiler's `-qmoddir=` flag sets the module output
directory but does not add the directory to the search path for using
modules. This is inconsistent with other compilers like the GNU Fortran
compiler's `-J` flag that does both. In order to make these consistent,
add the module output directory with a `-I` flag on the XL Fortran
compiler so that it will be searched when using modules too.
This fixes our `FortranModules` test's coverage of submodules on
Ninja + XL. That test places module files in a subdirectory that with
Ninja is not the current working directory when the compiler runs.
Fixes: #20400
Since commit d91b5a72cd (Ninja: Add support for CUDA nvcc response
files, 2019-05-30, v3.15.0-rc1~8^2) we use NVCC's `--options-file`
option to avoid long link command lines via a response file. However,
for non-device linking the host tools are used and the option does not
make sense. Update the logic to use `--options-file` only for device
linking. Linking with the host tools already has its own logic for
response files.
Fixes: #19954
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>
Fixes#17559
Replace our hard-coded default of cudart=static with a first-class abstraction to select the runtime library from an enumeration of logical names.
QCC is a wrapper around GCC, but it is not a fully transparent wrapper.
Some compile options need to be passed to GCC using a `-Wc` option.
QCC does not support --sysroot, so setting CMAKE_SYSROOT in a toolchain
file currently does not work. This means that it is likely that no one
is setting CMAKE_SYSROOT in existing QNC toolchain files. Override the
GCC option for sysroot in the QCC.cmake file with -Wc,-isysroot.
This exposes a further issue in that the QNX SDK does not follow the
same architectural folder structure as linux uses. That is, on linux
systems, architecture-specific libraries might be in
<sysroot>/usr/lib/<arch>
such as
/usr/lib/x86_64-linux-gnu/libcurl.so
CMake models this by suffixing the <arch> onto lib directories when
searching for libraries.
The QNX SDK is structured differently such that the <arch> should be
used as a prefix:
<sysroot>/<arch>/usr/lib
such as
<sysroot>/x86_64/usr/lib/libcurl.so
Add a variable for platform configuration to set whether to prefix or
suffix the <arch> and set that in the QCC.cmake.
Use the directory structure of the QNX SDK to compute the <arch> from
the implicit library directories. The assumption is that the arch will
be a single directory directly below the CMAKE_SYSROOT, below which the
usr/ prefix occurs.
It would not be appropriate to instruct users to make the <arch> part of
the sysroot when specified in the toolchain file because:
1. That would be non-DRY - The QCC wrapper already determines the <arch>
by the -V argument passed to the compiler, specified in the toolchain
file as the CMAKE_C_COMPILER_TARGET variable.
2. The includes in the QNX SDK are not below the <arch> directory.
So, the location of the <arch> in the full path is different on QNX
compared to, say an embedded linux platform, but the intent is the same.
Add documentation to recommend the use of CMAKE_SYSROOT in a QNX
toolchain file.
As the CMAKE_SYSROOT is always the same for QNX, it would be possible to
simply set it in QCC.cmake. However, that would change behavior for
existing users as when CMAKE_SYSROOT is set, files/paths outside of the
CMAKE_SYSROOT do not get found.
The <arch> prefixing is only enabled in cmSearchPath.cxx if
CMAKE_SYSROOT is set. This ensures that the user gets consistency in
the current state without CMAKE_SYSROOT, and gets better consistency
when using CMAKE_SYSROOT.
