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.
Extend tests added by commit fb3370b6a1 (MSVC: Add abstraction for
runtime library selection, 2019-04-10) to cover an empty value for
the property. It should result in no specific setting.
Issue: #19108
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.
Add COMMAND_ECHO option to the execute_process command. This will allow
execute_process to show the command it will run. Also add a cmake variable
CMAKE_EXECUTE_PROCESS_COMMAND_ECHO. Both the option and the variable can
be set to one of the following: STDERR|STDOUT|NONE. The command will be
printed to stderr or stdout or not at all.
Fixes: #18933
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
Kitware Robot
Kyle Edwards
Leonid Pospelov
Sebastian Holtermann
Zack Galbreath
Bartosz Kosiorek
Brad King
Christian Pfeiffer
Robert Maynard
Bill Hoffman
Saleem Abdulrasool