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.
This moves the `cmWorkerPoolInternal::WorkerT` class to `cmWorkerPoolWorker`
and changes the thread start interface to make it independent of the
`cmWorkerPoolInternal` type.
Don't pass the desired worker thread count to the `cmWorkerPool::Process()`
method but set it separately with the new `cmWorkerPool::SetThreadCount`
method. This allows calling `cmWorkerPool::Process()` repeatedly without
having to pass the thread count every time.
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>
The value of `CMAKE_VS_PLATFORM_NAME` is computed by Visual Studio
generators based on `CMAKE_GENERATOR_PLATFORM` or some default.
Prior to the VS 2019 generator, the default was always `Win32`.
However, for the `Visual Studio 16 2019` generator, the default is
based on the host platform.
Store the default in a new `CMAKE_VS_PLATFORM_NAME_DEFAULT` variable for
use by project code. This is particularly useful in toolchain files
because they are allowed to set `CMAKE_GENERATOR_PLATFORM` and so
`CMAKE_VS_PLATFORM_NAME` is not yet known. Of course the toolchain file
author knows whether it will set `CMAKE_GENERATOR_PLATFORM`, and if not
then `CMAKE_VS_PLATFORM_NAME_DEFAULT` provides the platform name that
will be used.
Fixes: #19177
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