The quoting introduced by commit eb3b3bacdc (CPack/NSIS: Fix uninstall
on Windows using "Apps & Features", 2021-09-13, v3.22.0-rc1~136^2)
created two errors in the uninstaller call: double quoting of the
uninstaller executable, and quotes added to the `_?=` argument which
does not support them. Simplify the command.
* add more possible directories for include file search
* enhance version detection from library and include files
* search for file pypy_decl.h when PyPy.h is not defined
Since commit 29ea94e17c (BinUtils: Avoid llvm-ar on Apple platforms,
2022-03-03, v3.21.6~1^2) we do not consider `llvm-ar` at all on Apple
platforms. However, there are existing cross-compiling use cases in
which the toolchain has `llvm-ar` but not `ar`. Prior to the
re-ordering in commit cf82300a63 (BinUtils: Clarify search logic and
make it more consistent, 2021-05-27, v3.21.0-rc1~119^2~2), we preferred
`ar` and then `llvm-ar`. Restore the original order for Apple.
Fixes: #23320
They are stored in a slightly different place with oneAPI than they
used to be in PSXE.
A similar change was made for Windows by commit 956160bb9a (IRSL: Fix
search for Windows redist files with Intel Classic compiler, 2021-09-23,
v3.22.0-rc1~88^2), which left a comment about the locations relative to
the Classic and oneAPI compilers.
Fixes: #23310
Since commit cf82300a63 (BinUtils: Clarify search logic and make it more
consistent, 2021-05-27, v3.21.0-rc1~119^2~2) we correctly prefer the
more-specific name `llvm-mt` over `mt` when using Clang. However, the
`llvm-mt` tool does not yet support all the flags we need in the
implementation of `vs_link_{exe,dll}`. Prefer plain `mt` for now.
Fixes: #23305
Fix logic added by commit 7fdd5128b1 (FindMatlab: Fix version selection
if a version is given, 2021-07-02, v3.22.0-rc1~66^2). Ensure that
`_list_index` is always initialized to -1, akin to `list(FIND)` not
finding a match.
Issue: #22377
Since commit cf82300a63 (BinUtils: Clarify search logic and make it more
consistent, 2021-05-27, v3.21.0-rc1~119^2~2) we correctly prefer the
more-specific name `llvm-ar` over `ar` when using Clang. However, on
Apple platforms, `llvm-ar` does not generate a symbol table that the
Apple linker accepts. Fall back to `ar` on Apple platforms.
Fixes: #23269
Revert commit 5efb6fb516 (FindThreads: Honor THREADS_PREFER_PTHREAD_FLAG
when pthread is found in libc, 2021-11-03, v3.21.5~4^2). The check for
the `-pthread` flag can pass on compilers like XL, that interprets it as
`-p -t hread` and returns zero. Prior to that commit, we did not use
the check in the `CMAKE_HAVE_LIBC_PTHREAD` code path. Now we do, it
succeeds, and we incorrectly add the `-pthread` flag for XL.
This change was backported to the 3.21 and 3.22 release series long
after they initially came out. Since there may be more cases where we
now add `-pthread` incorrectly, it is simplest to revert the change in
all release series pending further investigation.
Fixes: #23270
Since commit f90d15458a (FindGLUT: Use pkg-config to find flags if
available, 2021-06-11, v3.22.0-rc1~469^2), the `GLUT_LIBRARIES` may come
from `pkg-config`, in which case they may be `-l` flags instead of
absolute paths. Propagate `GLUT_LIBRARY_DIRS` to GLUT::GLUT too.
Fixes: #23229
Recent MCR versions have the following `VersionInfo.xml`:
<version>9.11.0.1837725</version>
Fix parsing of multiple digits in the version components
so that we do not mistake this for version `9.1`.
In commit a90d2a9eed (IntelLLVM: Add support for Intel LLVM-based
compilers, 2020-11-02, v3.20.0-rc1~89^2~20) the IntelLLVM depfile
generation flags were taken from `Platform/Windows-Intel-C`. Those
flags were added by commit a624a3e1b3 (Ninja: Use deps=gcc for Intel
Compiler on Windows, 2019-01-30, v3.14.0-rc1~30^2), which forgot to
account for commit 6d74e7870b (Ninja: Add dependencies on
system-provided header files, 2016-03-15, v3.6.0-rc1~265^2).
The `-QMD` option generates Makefile dependencies. The `-QMMD` option
generates Makefile dependencies, but excludes system header files.
Part of the BuildDepends test includes a header, cmake_pch.hxx, that
includes a second header, zot_pch.hxx. The test builds a pch file for
cmake_pch.hxx, touches zot_pch.hxx, then verifes that cmake_pch.hxx.pch
is regenerated based on the dependencies.
The cmake_pch.hxx contains `#pragma system_header` before it includes
zot_pch.hxx. `#pragma system_header` indicates that the portion of the
file following the pragma is to be treated as a system header.
When `-QMMD` is used to generate dependencies, the `#include` of
zot_pch.hxx is ignored because it `-QMMD` says to ignore system headers.
Using `-QMD` instead uses all headers when generating dependencies
and causes this test to pass. The Clang configuration in
Platform/Windows-Clang.cmake also uses the `-MD` option for generating
pre-compiled headers, instead of `-MMD`.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
In commit a624a3e1b3 (Ninja: Use deps=gcc for Intel Compiler on Windows,
2019-01-30, v3.14.0-rc1~30^2) we forgot to account for commit 6d74e7870b
(Ninja: Add dependencies on system-provided header files, 2016-03-15,
v3.6.0-rc1~265^2).
In commit fc3a1cbdd8 (CompilerID: Compiler extensions default detection,
2021-05-29, v3.22.0-rc1~52^2~2), extensions were assumed to be `OFF`
for Clang targeting the MSVC ABI. However, the `clang` and `clang++`
tools both seem to have extensions enabled by default even when
targeting the MSVC ABI.
This can be observed with the `RunCMake.CompileFeatures` test.
It fails with the GNU-like `clang/clang++` front-end, but removing
the above special case makes it pass. The test passes either way
with the MSVC-like `clang-cl` front-end.
Commit a9073db7 (IAR: update language specification detection, 2021-09-23)
added usage of the if() IN_LIST operation and forgot to account for it not
being available in CMP0057 OLD mode.
Push and temporarily enable the policy. Also avoid the unnecessary temporary
variable for the list.
Fixes#23147.
5efb6fb516 FindThreads: Honor THREADS_PREFER_PTHREAD_FLAG when pthread is found in libc
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6906
The `-pthread` flag tells the compiler/linker to link to additional
libraries needed for thread support (e.g. libatomic on riscv64). The
flag therefore should be used if requested using
`THREADS_PREFER_PTHREAD_FLAG` also when the pthread functions are
found in libc.
Move the `static` added by commit 8cce0ad32f (FindMPI: Fix missing
static warning in the mpi test source, 2021-06-30, v3.22.0-rc1~502^2) to
the beginning of the line.
Fixes: #23141
Since version 12.0 the GCC Fortran compiler has implemented "WG5/N1942",
which causes, if link-time opmization is enabled, obfuscation of hard-coded
string values in the compiler objects and its resulting ELF-binaries.
This causes the CMake-internal detection of the mangling scheme for the
naming of subroutines to fail. Thus we must ensure to have any link-time
optimization features to be disabled on the executable file we perform the
detection on.
The static libraries, however, must be build with LTO and non-LTO objects,
as that will ensure the verify step will operate on IPO objects, if building
those is requested by the system compiler flags.
Fixes: #23123
Signed-off-by: Björn Esser <besser82@fedoraproject.org>
Since commit f29e1874ad (Compiler/MSVC: use the `-external:I` flag for
system includes, 2020-05-19, v3.22.0-rc1~593^2) we use the new flag
followed by the include directory as a separate argument. Some versions
of `clang-cl` and `clang-tidy` do not support the flag unless the
include directory is attached to it, so use that form instead.
Fixes: #22979
Since commit f90d15458a (FindGLUT: Use pkg-config to find flags if
available, 2021-06-11, v3.22.0-rc1~469^2) we return early if pkg-config
provides the information. During review of that commit, code to
populate the legacy `GLUT_INCLUDE_DIR` result variable was removed from
that code path. Add code to provide it.
Also fix the test case to use `GLUT_INCLUDE_DIR`, the result variable
documented officially by the module.
Fixes: #23018
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>
Update the list of known versions.
Run the command
cmake -DBOOST_DIR=/path/to/boost_1_78_0 \
-P Utilities/Scripts/BoostScanDeps.cmake
to extract dependencies from the 1.78.0 source tree.
The dependencies differ from those of 1.77:
* The `log` component no longer depends on `date_time`.
Fixes: #23016
The current regular expression is able to match `/usr/lib/<arch>`,
`/usr/usr/lib/<arch>`, `/usr/usr/usr/lib/<arch>`, ... but not
`/lib/<arch>`.
This behavior ends up causing the detected architecture to
be x86_64-pc-linux-gnu when the Clang compiler is installed on
a "non-system" location (like /opt/llvm-13) which, in turn, makes
almost every 'find_library()' fail because the correct
architecture is x86_64-linux-gnu.
This is due to a typo in commit 764606e256 (CMakeDetermineCompilerABI:
Extract lib arch from implicit object file paths, 2021-04-05,
v3.20.1~10^2), which used `+` instead of `?`.
Since commit 94a84dc0af (FindPkgConfig: add pkgconf to the search list.,
2021-07-02, v3.22.0-rc1~468^2), `pkgconf` is preferred over `pkg-config`
if they appear in the same directory. In some environments,
`pkg-config` may be a wrapper that adds semantics beyond either
`pkgconf` or the normal `pkg-config`. Prefer `pkg-config` over
`pkgconf` in order to preserve the prior behavior in such environments.
Fixes: #22976
Update logic added by commit ecaca8c129 (GNUInstallDirs now aware of
conda lib directory requirements, 2021-09-08, v3.22.0-rc1~142^2).
When it is ambiguous if we are doing a conda install or a system
install prefer using the system library directory.
Fixes: #22962
C++ style comments were added by commit fc3a1cbdd8 (CompilerID: Compiler
extensions default detection, 2021-05-29, v3.22.0-rc1~52^2~2), but they
may not be supported by the default mode of some C compilers. Use
C-style comments instead. For consistency, do this for all languages.
Fixes: #22942
