Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++14 feature support when the
running compiler is known to have all features.
4783b842ba iOS: Only set the CMAKE_FIND_ROOT_PATH_MODE_* variables when not defined
5f5e3062cf iOS: Only look for packages in the provided CMAKE_FIND_ROOT_PATHs
94c5fa5f7a iOS: Allow setting multiple CMAKE_FIND_ROOT_PATH values
1011350694 iOS: Allow specifying CMAKE_MACOSX_BUNDLE in toolchain file
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3273
f06bf0fa57 FindBoost: Fix compiler features for `fiber` and `context`
684338aff6 FindBoost: Record compiler features for Boost 1.67 and above
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3266
Remove the 1.67 upper-bound on compiler feature computation so that with
newer versions we at least get it mostly right. Leave a comment with
notes about updating features for future versions.
Both CMAKE_FIND_ROOT_PATH_MODE_INCLUDE and
CMAKE_FIND_ROOT_PATH_MODE_LIBRARY are set to "ONLY" when cross
building to iOS, but appears that CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
was overlooked.
This causes packages to be searched for in the host system as well,
which is incorrect and can lead to linking issues.
Set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to "ONLY" as well.
CMAKE_FIND_ROOT_PATH_MODE_PROGRAM is not touched, because a user
might want to find programs / tools on the host system.
Currently the value is hardcoded to contain only the sysroot for
the respective darwin platform. This means that it can not be changed
in a custom toolchain file.
Instead of overriding the value, simply append it. This is similar
to how it is done in the Google provided Android toolchain file.
The usecase is to allow specifying addiitonal roots to look for
3rd party packages which are definitely not present in the default
sysroot.
Currently CMAKE_MACOSX_BUNDLE is always set to true when compiling
for iOS. This poses a problem when using the source file
variant of try_compile. Even if a custom value is passed via
the CMAKE_FLAGS option, it would still be overridden by the
Darwin.cmake file.
Only set the value in case no other value was provided before.
Use the infrastructure added by commit 646fb1a646 (CompileFeatures:
memoize C++ compilers with full language level support, 2019-03-27) to
avoid using a `try_compile` to check for C++11 feature support when the
running compiler is known to have all features.
In commit 8e4899fd6c (CompileFeatures: Record which C features the MSVC
compiler supports, 2019-04-12) our `cmake_record_c_compile_features`
macro was accidentally left not setting the `_result` variable, which
had previously been set by `_record_compiler_features`. The variable is
expected by the call site in `cmake_determine_compile_features` and used
to switch between "failed" and "done" reports. Set it now.
Also record `c_variadic_macros` only for cl 14 (VS 2005) and higher
because it is not supported before that version.
Restore path suffixes incorrectly removed by commit a62d50ec56 (Modules:
Replace coded PATHS with PATH_SUFFIXES, 2017-11-20, v3.11.0-rc1~293^2).
Hints do not participate in the usual bin/lib subdirectory search that
`<PackangeName>_ROOT` or `CMAKE_PREFIX_PATH` exhibit.
Fixes: #19185
On Windows systems, the need to retain library directories should not
nomrally occur. This can only occur on Unix like systems where a shared
library is being linked that has a dependency on another library which
is not being found in the default directories (e.g. libgfortran on BSD)
This also works around an issue introduced by !1694 in that the Visual
Studio generator does not handle link flags passed in
`INTERFACE_LINK_LIBRARIES` correctly, causing problems when using that
generator with Intel MPI in certain circumstances.
We do not add default warning flags on other compilers, and having
a warning flag in the default flags makes it hard for projects to
customize the warning level. They need to use string processing
to remove `/W3` from `CMAKE_{C,CXX}_FLAGS`. Therefore we should
drop it.
However, projects may be using string processing to replace `/W3`
with another flag, so we cannot simply drop it. Add a policy to
drop it in a compatible way.
Fixes: #18317
SunPro 5.15 supports `-std=c++14` and several C++14 features.
SunPro 5.14 accepts `-std=c++14` but does not update its definition of
`__cplusplus` or any other macro to distinguish it from `-std=c++11`,
so we need to blacklist a couple features that do work but that we
cannot report for that version. We can still support `cxx_std_14`.
Co-Author: Robert Maynard <robert.maynard@kitware.com>
Replace our hard-coded defaults for `/MD` and `/MDd` with a first-class
abstraction to select the runtime library from an enumeration of logical
names. We've long hesitated to do this because the idea of "runtime
library selection" 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 flags 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 CMP0091 to provide
compatibility.
Fixes: #19108
The Gentoo case added by commit 1673923c30 (FindBoost: Add support for
Boost 1.67 with Python version suffixes, 2018-03-18, v3.11.0~3^2) left
out the `.` version component separator and instead duplicated the RPM
case. Add the missing `.` now.
Fixes: #18743
VS 2019 Update 1 will fix its redist directories to be named `VC142`
instead of `VC141`. It will also use cl `19.21` instead of `19.20`
so we can use that to distinguish the versions.
Fixes: #19131
