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.
Simply remove `-Werror` flags from `CMAKE_<LANG>_FLAGS` to avoid failing
ABI detection if there happen to be warnings in the test project. For
example, `-Wunused-command-line-argument` warnings are common since the
ABI detection project may not exercise all the flags passed by users.
Fixes: #20305
CMake properly detects the toolkit directories as implicit system
includes, but CUDA compilers don't add explicit `-isystem` markups to
these directories when compiling CUDA code. Due to this limitation,
allow users to explicitly specify these directories as SYSTEM dirs.
Fixes: #16464, #19864
In commit 97bca2f9fa (Android: Use unified toolchain in NDK r19+,
2019-07-26, v3.16.0-rc1~342^2) we hard-coded use of the unified
toolchain for NDK r19+ and skipped most of the old detection logic.
However, in that fast path we left out setting `_CMAKE_TOOLCHAIN_PREFIX`
for `CMakeFindBinutils` to select the matching binutils. Add it.
Fixes: #20038
807a129f3c Find{BLAS,LAPACK}: Include parent of points directory in search
fe86dc43fe Find{BLAS,LAPACK}: Fixed an incorrect use of a macro argument
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4306
afcd9fe669 AIX: Add an option to disable automatic exports from shared libraries
67f30811ce AIX: Improve name of internal symbol export list file
0ffd54f094 AIX: Add ExportImportList option to skip the object files
0dcfb63cb9 AIX: Revise ExportImportList to build output more incrementally
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4308
This adds logic to properly handle Swift executables. Only executables
marked as exporting symbols will now generate module interfaces for the
executable.
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).
The CPack OSXX11 generator has not had any updates since 2011 except as
part of sweeping maintenance changes. It also creates packages with a
OSXScriptLauncher binary that has only ppc and i386 architectures which
are not supported by Apple anymore. Furthermore, the generator is not
even mentioned in our documentation. Add a deprecation warning.
Fixes: #20235
Since commit 0f150b69d3 (AIX: Explicitly compute shared object exports
for both XL and GNU, 2019-07-11, v3.16.0-rc1~418^2~2) we always export
all symbols from shared libraries by default. Add a new target property
called `AIX_EXPORT_ALL_SYMBOLS` that can be explicitly set to OFF to
suppress this behavior and export no symbols by default.
Fixes: #20290
This is required if MKLROOT points to the subdirectory .../mkl/ instead of
the root of an Intel MKL library installation. Only in this case the MKL
will be searched starting from the parent directory, to detect relevant
dependencies in parallel subdirectories, like 'compiler' and 'tbb'.
In commit 0f150b69d3 (AIX: Explicitly compute shared object exports for
both XL and GNU, 2019-07-11, v3.16.0-rc1~418^2~2) we dropped use of the
old `CMAKE_XL_CreateExportList` cache entry for XL exports. However,
some people were setting the value to an empty string as a way to
disable automatic export of symbols. Restore this behavior when the
option is explicitly set to an empty string.
Issue: #20290
If a project writes `include(GNUInstallDirs)` before `project()` then
`CMAKE_SYSTEM_NAME` may not be set and an incorrect `LIBDIR` may be
computed. Warn about this case.
Update `_CUDAToolkit_find_and_add_import_lib` to create and add
dependencies to a target in one step that shared a single guard against
repeated definitions. Otherwise we were adding dependencies again on
every call.
Fixes: #20282
In the case that we use ExternalProject_Add to drive the subdirectory
build, replace the `forcebuild` step with the official `BUILD_ALWAYS`
option.
Issue: #20179
45d21dd5d4 CUDAToolkit: Use CMAKE_FIND_ROOT_PATH for all sdk lib searches
e357772f20 CUDAToolkit: Use HINTS as it has higher precedence for searches
c6ec51c625 CUDAToolkit: functions names now use CMake's reserved namespace
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4278
Previously the search in the dynamic linker paths 'LIB', 'LD_LIBRARY_PATH'
and 'DYLD_LIBRARY_PATH' was dependent on the value of the environment
variable 'MKLROOT'. If MKLROOT was given, the dynamic linker paths where
not searched. This seems slightly counter-intuitive.
This PR changes the behavior so that MKLROOT is searched first, but if
unsuccesful, the dynamic linker paths are tried as well.
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.
`clang-tidy` does not infer driver mode if it is not provided with a
JSON compilation database. This is exactly the way cmake launches it.
Hence clang-tidy will only use the default driver mode. Add an explicit
driver mode argument to avoid this.
Brad King