Documentation for environment variables that control the default
generator selection:
* CMAKE_GENERATOR
* CMAKE_GENERATOR_INSTANCE
* CMAKE_GENERATOR_PLATFORM
* CMAKE_GENERATOR_TOOLSET
Add a `CMAKE_FIND_PACKAGE_PREFER_CONFIG` variable to tell
`find_package` calls to look for a package configuration file
first even if a find module is available.
Fixes: #16805, #19236
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
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
2c43fb5be3 FindThreads: Fix pthread library check in GHS Multi Generator
0404efe786 GHS: Add support for GHS Multi Generator in Linux
2060a1445c Tests: Fix file name case in GHS object library test
ddad70c8a4 Tests: Run GHS tests in a separate ctest process
f7dca1fc97 GHS: Fix include-what-you-use and clang-tidy diagnostics
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3006
The user package registry populated by the `export()` command causes
side effects outside the build and source directories. Such effects
should be opt-in rather than op-out. Introduce a policy to change
default behavior of `export(PACKAGE)` to do nothing.
376138fe0c Help: CMAKE_MACOSX_BUNDLE is ON for iOS/tvOS/watchOS
f7d602b572 Help: Example of tweaking iOS/tvOS/watchOS build
4a9e2e4f35 Help: find_package with fat iOS libraries
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3047
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.
We now identify IBM's Clang-based XL compilers, which define
`__ibmxl__`, as `XLClang` rather than `XL`. In order to support
existing project code that checks for `XL`, add a policy whose OLD
behavior is to present the compiler id as `XL` and whose NEW behavior is
to present the compiler id as `XLClang` as we really detect it.
In commit beb991110d (Remove now-unused code once used on IRIX,
2019-01-11, v3.14.0-rc1~167^2) we removed remnants of IRIX support.
Also remove remnants of MIPSpro compiler support.
Since commit 2e91627dea (ParseImplicitIncludeInfo: add Fortran implicit
include handling, 2019-01-25, v3.14.0-rc1~73^2) we actually populate
`CMAKE_Fortran_IMPLICIT_INCLUDE_DIRECTORIES` for the first time. This
value may be useful to project code to pass to other tooling that wants
to preprocess the way Fortran does, so we should compute the value.
However, compilers like `gfortran` do not actually search their own
implicit include directories for `.mod` files. The directories must be
passed via `-I` in order for `.mod` files in them to be found.
Since Fortran has no standard library header files that we need to avoid
overriding, it is safe to *not* filter out implicit include directories
from those passed explicitly via `-I` options. Skip this filtering so
that include directories specified by project code to find `.mod` files
will be searched by the compiler even if they happen to be implicitly
searched by the preprocessor.
Fixes: #18914
Brad King