Since commit 07223c5c27 (Tutorial: Update Step 5 to work on Windows,
2020-02-18, v3.18.0-rc1~655^2) the logic does not work on non-Windows
platforms when cmake is re-run on an existing build tree. It is also
more complicated than we'd like for a tutorial example. Avoid the need
to consider the `m` library case by performing the check as C++.
Since `check_cxx_symbol_exists` cannot handle overloaded functions
like `exp` and `log`, check with `check_cxx_source_compiles` instead.
This also presents a more general-purpose example in the tutorial.
Fixes: #23524
Extend the change from commit e01990999a (Ninja: On Windows, select the
compiler occurring first in PATH, 2020-04-17, v3.18.0-rc1~291^2) to
apply to the MSYS/MinGW Makefiles generators too. Drop the implied
`gcc` and `g++` default compilers. This allows MinGW/Clang environments
to work out of the box.
Inspired-by: Mehdi Chinoune <mehdi.chinoune@hotmail.com>
Fixes: #23542
Add a new property, INTERFACE_HEADER_SETS_TO_VERIFY, which contains
a list of header sets that should be verified by
VERIFY_INTERFACE_HEADER_SETS.
Fixes: #23522
Commit 496ec6036f (Help: Add Sphinx 'versionadded' directives to each
top-level document, 2020-07-06, v3.19.0-rc1~558^2) added the
versionadded directive to many variables, but it wrongly detected the
commit a6d3f5418c (Help: Clarify documentation of
CMAKE_COMPILER_IS_GNU{CC,CXX,G77}, 2016-09-14, v3.7.0-rc1~120^2~1) as
the origin for these variables. In reality, these variables were
introduced in commit f5d95fb078 (Complete rework of makefile generators
expect trouble, 2002-11-08, v2.4.0~4935).
LLVM Flang (https://github.com/llvm/llvm-project/tree/main/flang) is an LLVM
Fortran compiler that shares the same name as Flang (also known as Classic
Flang). Classic Flang is in active development and is already identified by
CMake as Flang. As such, LLVM Flang will be identified as `LLVMFlang`.
Fixes: #22387
Add LINK_LIBRARIES test to demonstrate static linking of transitive
dependencies.
Add STATIC_TARGET argument to pkg_check_modules() and pkg_search_module().
Influences the properties of target produced by IMPORTED_TARGET.
When enabled: target's properties will be populated from <XXX>_STATIC_*
variables instead of from <XXX>_* variables.
Update existing tests concerning properties of targets produced via
IMPORTED_TARGET, to test STATIC_TARGET variant too.
Update existing tests concerning <XXX>_* variables to test <XXX>_STATIC_*
variables too.
Breaking changes to pkg_check_modules() and pkg_search_module():
- Variables CMAKE_FIND_LIBRARY_PREFIXES and CMAKE_FIND_LIBRARY_SUFFIXES can no
longer be used to influence library lookup (i.e. the internal call to
find_library()), because FindPkgConfig now internally relies on these
variables to differentiate between shared and static library lookup.
Prefer CMAKE_SHARED_LIBRARY_PREFIX + CMAKE_SHARED_LIBRARY_SUFFIX, or
CMAKE_STATIC_LIBRARY_PREFIX + CMAKE_STATIC_LIBRARY_SUFFIX, depending on
whether you wish to impact static or shared lookup.
- <XXX>_LINK_LIBRARIES will now be populated only with libraries
located via CMAKE_SHARED_LIBRARY_PREFIX + CMAKE_SHARED_LIBRARY_SUFFIX match
- <XXX>_STATIC_LIBRARIES now processes -framework options
- <XXX>_STATIC_LDFLAGS_OTHER now processes -framework options
- <XXX>_STATIC_CFLAGS_OTHER now processes -isystem options
- <XXX>_STATIC_INCLUDE_DIRS now processes -isystem options
Fixes: #21714
In commit 8d7e80cf3d (find_* commands: add control over Windows registry
views, 2022-04-16) we added documentation that is repeated by multiple
find commands. Move it to a dedicated manual section to avoid duplication.
Add policy CMP0137 to propagate both our builtin variables and those
listed by `CMAKE_TRY_COMPILE_PLATFORM_VARIABLES` to `try_compile`
whole-project builds.
Inspired-by: Alexander Neumann <Alexander.Neumann@hamburg.de>
Fixes: #23219
This commit updates the documentation so that the component examples are
specified using title case to match convention used in both the existing
`Installing Exports` section and in the "Mastering CMake" book.
Add `COMPILE_WARNING_AS_ERROR` target property and supporting
`CMAKE_COMPILE_WARNING_AS_ERROR` variable.
`COMPILE_WARNING_AS_ERROR` is initialized by
`CMAKE_COMPILE_WARNING_AS_ERROR`. It is a boolean variable. If it is
true, it expands to a different flag depending on the compiler such that
any warnings at compile will be treated as errors.
Supports compiler ids that I could find a relevant flag for.
