Extend the `-T <toolset>` option to support a `buildsystem=` field with
the Xcode generator. Add a `CMAKE_XCODE_BUILD_SYSTEM` variable to
inform project code about the selected build system variant.
Since commit 83ddc4d289 (VS: Do not select a Windows SDK too high for
current VS version, 2017-08-07, v3.13.0-rc1~72^2~2) we enforce a maximum
SDK version for the VS 2015 generator. The blog post linked in the
original commit is no longer available, but it can be seen here:
* https://web.archive.org/web/20190108032520/https://blogs.msdn.microsoft.com/chuckw/2018/10/02/windows-10-october-2018-update/
In particular, it states:
> VS 2015 Users: The Windows 10 SDK (15063, 16299, 17134, 17763)
> is officially only supported for VS 2017.
However, in some circumstances a higher version can be used.
Add a `CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION_MAXIMUM` to override the
generator's default maximum SDK version.
Fixes: #20633
Ninja 1.10 was released in Jan 2020 and has the features we need
to support Fortran. Replace documentation that mentions Kitware's
branch with mention of Ninja 1.10+ instead.
Also rename `..._DEFAULT_BUILD_FILE_CONFIG` to `..._DEFAULT_BUILD_TYPE`.
These name changes make the variables meaningful for future use by other
generators.
Many users will want to use the Ninja Multi-Config generator like a
traditional Visual Studio-style multi-config generator, which doesn't
mix configurations - custom commands are built using target executables
of the same configuration the command is for. We do not want to force
these people to generate an N*N build matrix when they only need N*1,
especially if they have lots of targets. Add a new variable,
CMAKE_NINJA_CROSS_CONFIG_ENABLE, to opt-in to the cross-config build
matrix.
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
-- Rename platform script so it runs before initial try_compile() in
project() command.
-- Fix incorrect variable name GHS_OS_DIR_OPTION
-- Remove unnecessary ".*" from REGEX expression for GHS_CANDIDATE_OS_DIRS
-- Forward GHS_OS_DIR_OPTION to try_compile() and preserve trailing
whitespace of the variable.
-- Forward GHS platform variables to try_compile()
CMAKE_TRY_COMPILE_PLATFORM_VARIABLES only worked for source signature try_compile()
-- Update tests to no longer add GHS platform variables to try_compile()
-- Avoid linker error in GhsMulti/GhsMultiCompilerOptions/CMakeLists.txt by building library
-- 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.
-- Set output and object file locations
-- Suffixes are no longer being forced but will now follow the target properties
By default GHS tools have no suffix for executable files so
CMAKE_EXECUTABLE_SUFFIX was changed to meet this behavior
-- Remove #if 0 blocked out code; it has been replaced.
Forcing the -relprog option has been removed from non-kernel executable targets.
The default value of this option (if it is even available) is determined by the
tool-chain for the specified target and platform (Some tool-chains default to
-locatedprogram). The use of -relprog can have unexpected results as it cannot
always produce a fully relocated executable.
-- Clarify use of CMAKE_BUILD_TYPE to control build configuration
Add this generator *without* support for specifying the target
architecture in the generator name. cmake-gui will be taught
to provide a field for this, and command-line builds can use -A.
Also, teach this generator to select a default target architecture
based on the host architecture.
Fixes: #18689
Inspired-by: Egor Pugin <egor.pugin@gmail.com>
-- Update how the latest OS is determined; scan the location GHS_OS_ROOT and sort it
No longer use registry settings looking for installations
The registry values are assigned in installation order for Green Hills tools not version order
Filter out files from the list of directories (i.e if int1234.zip and int1234 are both in root folder)
-- Use the specified toolset located within GHS_TOOLSET_ROOT
-- Update how the latest toolset is determined; scan the location GHS_TOOLSET_ROOT and sort it
No longer use registry settings looking for installations
The registry values are assigned in installation order for Green Hills tools not version order
-- Update to use gbuild.exe from the proper toolset
-- Clarify that CMAKE_MAKE_PROGRAM should not be set by user.
-- Detect some toolset changes when regenerating project files
This could occur if GHS_TOOLSET_ROOT was changed by user after the initial project generation
This could occur if CMAKE_MAKE_PROGRAM was changed at the command line
-- Use placeholder values for CMAKE_<LANG>_COMPILER
The MULTI build system only uses gbuild to build a project
gbuild uses the project file to determine which set of compilers to use based on target platform and architecture
because compiler detection is skipped, placeholder values are used so that CMake does not complain
-- Update -A option to choose target architecture.
-- Update commentary about which variables are used to control toolset and target settings
-- Remove setting CMAKE_SYSTEM_PROCESSOR because the value is overwritten to be "" by subsequent CMAKE processing
The last KDevelop3 release was many years ago, in 2008 I think.
I haven't seen or read about anybody using KDevelop 3 since a
long time, so I think it can safely be removed from CMake.
KDevelop 4 (first released in 2010) has its own proper CMake
support now, independent from this generator.
Alex
Visual Studio 2017 supports multiple instances installed on a single
machine. We use the Visual Studio Installer tool to enumerate instances
and select one. Once we select an instance for a given build tree, save
the result in `CMAKE_GENERATOR_INSTANCE` so we can re-configure the tree
with the same instance on future re-runs of CMake.
Fixes: #17268
Add variable `CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES` to optionally
exclude files from outside the project root from the project file
written by the CodeBlocks extra generator. This optionally restores
logic that had been removed by commit v2.8.3~40^2 (CodeBlocks Generator:
Do not omit files in the project file listing, 2010-10-05) in response
to QTCREATORBUG-2250.
Issue: #12110Fixes: #17188
In the `Visual Studio 15 2017` generator, if the `VS150COMNTOOLS`
environment variable points at a specific VS 2017 instance reported by
the Visual Studio Installer tool, use that as the preferred instance.
Inspired-by: Iyyappa Murugandi <iyyappam@microsoft.com>
Fixes: #16846
