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.
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
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
032e969879 Merge branch 'backport-FindBoost-msvc-toolset-14.2'
717e85418b FindBoost: Add support for MSVC toolset version 14.2
9010f5c18a FindBoost: Add support for MSVC toolset version 14.2
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3221
Use the infrastructure added by commit f92ccbc306
(CompileFeatures: memoize C compilers with full language level support)
to avoid using a `try_compile` to check for C 90/99/11 feature support when the running compiler is known to have a fixed set of feature support.
-- When using default values for the external project forward GHS platform
variables so that the external project builds with the same tools as
the original project.
-- Fix issue with bad top level project when GHS_PRIMARY_TARGET is set but has
no value. In this case treat it as unset and use default value.
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++98 feature support when the
running compiler is known to have all features.
613ac56e50 Add a test to verify meta-feature parity with granular features
b0f46c48f6 CompileFeatures: Now able to presume full language level support
646fb1a646 CompileFeatures: memoize C++ compilers with full language level support
0d641fcfad Tests: Remove outdated portion of CompileFeatures genex test
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3176
Previously compilers that only supported the meta-level flags
would not have any of the granular features listed. Now we
presume that they have full support and enable all the features.
Update granular feature tests to skip the actual compilation
checks for the presumed features.
Previously compilers that had full support for a language standard level
were still verified every time a new build directory was created. Now
we record this information and insert the correct granular compile
features instead of doing a `try_compile`.
In some cases GCC reports *relative* implicit include directories. They
are computed adaptively with respect to the current working directory
such that the effective implicit include directory is an unchanging
absolute path. Teach our implicit include directory extraction to
recognize such paths and normalize them.
Fixes: #19133
Since VS 2017's v141 toolset there is no longer a simple equation to
calculate the redist name, dll version, and VS IDE version from just the
MSVC toolset version. Refactor the logic to use hard-coded values and
warn when a new version is not supported.
Fixes: #19125
