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
In order to keep infinitely-recursive scripts from causing a stack
overflow in the CMake executable, CMake now imposes a maximum
recursion limit before issuing an error message. The limit can be
adjusted at runtime with CMAKE_MAXIMUM_RECURSION_DEPTH.
Fixes: #18694
-- Detect GHS compiler and version
Detect ARCHITECTURE_ID for PPC / ARM / 86 targets
Detect PLATFORM_ID for Integrity and Integrity178 platforms
Using defines specified in the documents for the compilers: 201416 PPC / 201754 ARM / 201714 86
-- Fallback C/CXX compiler ID to GHS if not otherwise detected and using GHS MULTI generator
Works around issue with some GHS compilers not setting __ghs__ compiler define
-- Tweak Compiler ID checking so major id of 002017 is not replaced with 217
-- Prefer try_compile() library targets when testing for working GHS compilers
-- Avoid CMake errors if reading past end of file for checking if file is PE executable
-- Check the property "ghs_integrity_app" on executables to set [INTEGRITY Application]
If the property is not set then check if an integrate file is one of the source files (.int file).
Dynamic Downloads that do not have an integrate file can use this property along with setting
the compiler flag "-dynamic".
-- Remove parsing for -dynamic flag; it is only used to print a comment
The MULTI GUI will show if it is a Monolith or Dynamic Download application
-- Use project references to specify which executables are part of the Integrity Application
Usually Implicit Dependency Analysis will ensure that executable targets
become part of the application. This does not work for Dynamic Download without integrate files.
Use `add_dependencies(dd vas)` to mark that the vas target is part of dd target.
-- Update file locations in the Integrate files.
-- Do not use CMAKE_C_FLAGS_RELEASE flags when CMAKE_BUILD_TYPE is empty
if CMAKE_BUILD_TYPE was not set the generator would use Release settings
this does not match the documented behavior of CMAKE_BUILD_TYPE
-- CMAKE_C_FLAGS_<CONFIG> not used when -kernel is present
Fixes issue where CMAKE_C_FLAGS_<CONFIG> is ignored when -kernel option is present as a compiler option
When the -kernel option is added to an executable it uses a different set of language flags
This does not occur -kernel=<type> is used or if it is added as part of a link flag
The variables CMAKE_<LANG>_GHS_KERNEL_FLAGS_<CONFIG> are removed
NOTE: By default this only added the flag -ldebug which links in the debugger library.
-- Separate compiler options by newlines
