The purpose of the `Boost::dynamic_linking` interface library is to
cause `BOOST_ALL_DYN_LINK` to be defined. Do this on all platforms
instead of just Windows.
In particular, using Boost::log trivial_logger requires to set
BOOST_ALL_NO_LIB when Boost::Log is compiled as dynamic library.
Fixes: #17813
Our check for just `pthread_create` is not sufficient because there are
cases where that symbol may be found in libc but not all of pthreads.
We first tried to address this in commit e9a1ddc594 (FindThreads:
Replace the pthread symbol checking in libc., 2018-11-18,
v3.14.0-rc1~292^2) by switching to `pthread_kill`, but that had to be
reverted by commit 18320230ec (FindThreads: Revert libc symbol check to
pthread_create, 2019-02-27, v3.14.0-rc3~6^2) because there are other
cases where `pthread_kill` is in libc but the rest of pthreads is not.
Update our check to try a complete program using pthreads as an actual
application might.
Fixes: #18994
Since commit 11da882a12 (Apple: Introduce separate system name for iOS,
tvOS, and watchOS, 2018-01-15, v3.14.0-rc1~14^2~1) we support setting
`CMAKE_SYSTEM_NAME` to `iOS`. Existing iOS toolchain files already
set `IOS` as a short-hand variable, so do the same here.
e53a968ed5 MSVC: Use -D instead of /D in RC_FLAGS
1a281a1acd RC: Pass output file in a way that llvm-rc 7 and below understand
fa339ced67 CMakeVersion.rc: Avoid preprocessor definitions to support llvm-rc
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3007
Update the component added by commit 513e77550d (FindPython: Introduce
NumPy component, 2018-12-12, v3.14.0-rc1~95^2). The `numpy/`
sub-directory should not be part of the include directory. It should be
part of the `#include` line.
Java 9 restructured the standard location of the AWT libraries due to
the removal of the JRE/JDK separation. We should check all possible
combinations of subdirectories to the Java root directories to ensure
that the libraries will be found after an upgrade.
Furthermore, a root directory would contain both, include and library
paths, so the search should be unified to ease maintenance on the
module.
In commit b6f6cac378 (ExternalProject: add LOG_DIR option that allows
overriding of log location, 2018-10-12, v3.14.0-rc1~515^2~1) the log
directory got its own option. The intention was to fall back to the
stamp directory by default. However, the implementation actually only
falls back to the same default as the stamp directory and does not
consider a custom stamp dir.
Update the default log dir computation to fall back to whatever is the
final selection for the stamp dir.
Fixes: #19000
Code removed for MIPSpro by commit 214fcefa52 (Remove now-unused code
once used for MIPSpro on IRIX, 2019-02-21) actually changed a
public-facing API by dropping the `<prefix>_COMPILER_IS_MIPSpro`
definition from the generated compiler detection header. Restore the
definition hard-coded to `0` since the compiler will never be MIPSpro.
Reported-by: Hans Johnson <hans-johnson@uiowa.edu>
Prior to LLVM 8.0, `llvm-rc` does not recognize `/fo` without a space
after it. Add the space unconditionally because MS `rc` accepts it too.
Issue: #18957
Since commit e9a1ddc594 (FindThreads: Replace the pthread symbol
checking in libc., 2018-11-18, v3.14.0-rc1~292^2) we check libc for
`pthread_kill` instead of `pthread_create`. However, on FreeBSD
`pthread_kill` is in libc but not `pthread_create`. Discussion in the
original merge request for the above commit also considered
`pthread_key_create`, `pthread_self`, and `pthread_attr_init`. Every
symbol seems to have some reason it is not an appropriate choice.
Revert to the pre-3.14 behavior of using `pthread_create` pending
further investigation.
On Linux containers (tested with LXC and Docker) getconf returns the
host CPU count.
Use nproc with a higher priority if available to get the container's
allocated CPUs instead of the non-accessible host count.
The `FindOctave` module added by commit 170bcb6fdc (FindOctave: Add
module to find GNU octave, 2018-11-17, v3.14.0-rc1~283^2) has a few
problems in its implementation that need to be worked out before the
module can be included in a CMake release. These were missed during
review. Remove the module for now. It can be restored later with a
fresh review.
Issue: #18991
d9d285c5ad jsoncpp: Fix include order for build within CMake
0d489fab19 libuv: fix atomic ops compilation with xlclang
1699f5c231 Utilities: Suppress warnings in third-party code when using XLClang
f709089d84 XLClang: Extract compiler implicit include directories
5c41386357 XLClang: Add policy CMP0089 to present as XL for compatibility
8278237933 XL: Remove overlap with the new XLClang compiler ID
6f5cf2d2c6 XL: Revert "Recognize compilers identified by __ibmxl__"
90c6156aa8 XLClang: Add a new compiler ID for the clang-based XL compiler
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2921
When using a VS generator with `-T llvm`, MSBuild relies on the "LLVM
Compiler Toolchain" VS Extension. This does not put `clang-cl` in the
`PATH` inside the build, and LLVM no longer provides a `cl` replacement
either. Therefore we need another way to extract the path to the
`CMAKE_{C,CXX}_COMPILER`. Fortunately the LLVM VS integration provides
a `$(ClangClExecutable)` macro we can reference to get the path.
Fixes: #18983
In commit e9a1ddc594 (FindThreads: Replace the pthread symbol checking
in libc., 2018-11-18, v3.14.0-rc1~292^2) we switched to checking for
`pthread_kill` in libc but did not update the symbol check's header file
to match. Add `signal.h` to get `pthread_kill`. Keep `pthread.h`
anyway since the purpose of the check is to verify that the pthread API
works.
Fixes: #18984
In commit 6555286c55 (XL: Add C and C++ language level flags,
2017-04-27, v3.9.0-rc1~184^2) we added support for both the traditional
XL compiler and the Clang-based variant used on Linux. The latter is
now handled by `Modules/Compiler/XLClang-{C,CXX}.cmake` using the
`XLClang` compiler id. Drop the corresponding content from the
traditional XL compiler modules.
Revert commit eb1a9be4b6 (XL: Recognize compilers identified by
__ibmxl__, 2018-03-05, v3.11.0-rc3~4^2). It is no longer needed because
we now use `__ibmxl__` to identify with compiler id `XLClang`.
