Add documentation for both the CMake variable and environment variable
of this name pattern. Update references to these names to link to their
documents. Clarify the pattern used to construct their names.
Add new `version=` parameter in the toolset setting to select the
version. Add variable `CMAKE_VS_PLATFORM_TOOLSET_VERSION` to hold the
version, if one is set (blank indicates default).
Fixes: #17549
* Introduce `CMAKE_PROJECT_VERSION` and the corresponsing components:
`CMAKE_PROJECT_VERSION_MAJOR`, `CMAKE_PROJECT_VERSION_MINOR`,
`CMAKE_PROJECT_VERSION_PATCH` and `CMAKE_PROJECT_VERSION_TWEAK`.
* `CPack` module use `CMAKE_PROJECT_VERSION_MAJOR`,
`CMAKE_PROJECT_VERSION_MINOR` and `CMAKE_PROJECT_VERSION_PATCH`
to initialize corresponsing CPack variables.
Create `CMAKE_VS_SDK_*_DIRECTORIES` variables to tell the VS generator
how to populate fields in `.vcxproj` files that specify SDK directories.
Fixes: #17908
This can be used for example to organize all following targets into one
Visual Studio folder:
set(CMAKE_FOLDER Libraries)
add_subdirectory(libA)
add_subdirectory(libB)
set(CMAKE_FOLDER Executables)
add_subdirectory(progA)
Another possibility is using the current directory name for all
following targets in subdirectories:
get_filename_component(dirname "${CMAKE_CURRENT_SOURCE_DIR}" NAME)
string(APPEND CMAKE_FOLDER "/${dirname}")
Teach `cmake_minimum_required` and `cmake_policy(VERSION)` to support a
version range of the form `<min>[...<max>]`. Define this to mean that
version `<min>` is required, but known policies up to those introduced
by `<max>` will be set to `NEW`. This will allow projects to easily
specify a range of versions for which they have been updated.
This sets variables like PROJECT_HOMEPAGE_URL, which can be
used as default values for various things (packaging modules,
doxygen defaults, etc.). Some packaging modules have been
updated to do this as part of this commit.
Co-Author: Craig Scott <craig.scott@crascit.com>
The docs for CMAKE_PROJECT_NAME and CMAKE_PROJECT_DESCRIPTION
were erroneously documenting the behavior of PROJECT_NAME and
PROJECT_DESCRIPTION respectively. Fix these and update the
project() docs to also mention CMAKE_PROJECT_NAME and
CMAKE_PROJECT_DESCRIPTION.
Fixes: #17815
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
This removes duplicated code for per-config variable initialization by
providing a `cmake_initialize_per_config_variable(<PREFIX> <DOCSTRING>)`
function.
This function initializes a `<PREFIX>` cache variable from `<PREFIX>_INIT`
and unless the `CMAKE_NOT_USING_CONFIG_FLAGS` variable is defined, does
the same with `<PREFIX>_<CONFIG>` from `<PREFIX>_<CONFIG>_INIT` for every
`<CONFIG>` in `CMAKE_CONFIGURATION_TYPES` for multi-config generators or
`CMAKE_BUILD_TYPE` for single-config generators.
This enables configuration of build parallelism with the Ninja generator by
passing arguments on the command line to CMake. For example,
cmake \
'-DCMAKE_JOB_POOLS:STRING=compile=5;link=2' \
-DCMAKE_JOB_POOL_COMPILE:STRING=compile \
-DCMAKE_JOB_POOL_LINK:STRING=link \
~/src/MyProject
CodeBlocks uses his own compiler ID string which may differ from
CMAKE_<LANG>_COMPILER_ID. In particular CodeBlocks supports a large
number of different compiler configurations (with different IDs)
This commit adds a cache variable "CMAKE_CODEBLOCKS_COMPILER_ID",
so the user might adjust it when needed.
Add a `Fortran_COMPILER_LAUNCHER` target property like those added for C
and CXX by commit v3.4.0-rc1~450^2 (Add options to launch the compiler
through tools like ccache or distcc, 2015-06-04) and CUDA by commit
v3.10.0-rc1~531^2 (CUDA: Add option to run the compiler through launcher
tools, 2017-06-09).
Fixes: #17499
Introduces CPACK_DEFAULT_DIRECTORY_INSTALL_PERMISSIONS
variable which adds support for functionality introduced
by CMAKE_DEFAULT_DIRECTORY_INSTALL_PERMISSIONS variable.
Fixes#17333
# Conflicts:
# Help/release/dev/cmake-default-dir-install-permissions.rst
Introduces CMAKE_DEFAULT_DIRECTORY_INSTALL_PERMISSIONS
variable which enables the user to specify the default
permissions for directory creation. This setting is then
used to auto set the permissions on directories which
are implicitly created by install() and file(INSTALL)
commands such as CMAKE_INSTALL_PREFIX directories.
Some are user facing.
Found using
codespell -q 3 --skip="./Utilities" -I .cmake-whitelist.txt`
whereby the whitelist contained:
ans
dum
helpfull
emmited
emmitted
buil
iff
isnt
nto
ot
pathes
substract
te
todays
upto
whitespaces
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 cache entry `CMAKE_GENERATOR_INSTANCE` to hold the instance location
persistently across re-runs of CMake in a given build tree.
For now we reject the option by default if explicitly set. It will be
implemented on a per-generator basis. Pass the setting into try_compile
project generation. Add a RunCMake.GeneratorInstance test to cover
basic use cases for the option. Verify that `CMAKE_GENERATOR_INSTANCE`
is empty by default, and that it is rejected when the generator does not
support a user setting.
Issue: #17268
Create a `CMAKE_<LANG>_COMPILER_VERSION_INTERNAL` variable to hold
a secondary/internal compiler version number detected at the same
time as the primary compiler version. This will be useful for some
compilers where we need such a number to determine correct usage.
Inspired-by: Stefan Andersson <tfosm@hotmail.com>
Suggested-by: Norbert Lange <norbert.lange@andritz.com>
Issue: #17264
David Demelier