Since LCC 1.26.03, compiler developers decided to rename
liblfortran to libgfortran (internal reference: mcstbug#131633),
and despite it's stated that "-llfortran will be automatically
treated as -lgfortran", it actually does not work (and there's
even no symlinks like liblfortran.* -> libgfortran.*); so we
have to explicitly choose which library we have to link in.
Fixes: #23646
Revert commit 020976d637 (FindPkgConfig: Populate
_STATIC_LINK_LIBRARIES. Add STATIC_TARGET., 2021-12-31,
v3.24.0-rc1~105^2). Several regressions have been reported.
Revert the feature pending further discussion and design work.
Issue: #21714Fixes: #23642
7c79fde5fb Xcode: automatically create Info.plist for signing during compiler id
116cc5a57b cm_cxx_features: filter out warnings from Xcode 14
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7391
The change to `_ep_add_mkdir_command` in commit 5fbac2bb24
(ExternalProject: Move inline scripts to separate files, 2022-01-22,
v3.23.0-rc1~101^2) did not account for the possibility that
`CMAKE_CFG_INTDIR` is `$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)`
instead of just the configuration name. Pass the value into the helper
script on the command line so that the native buildsystem placeholders
are evaluated.
Fixes: #23645
The change to `_ep_add_mkdir_command` in commit 5fbac2bb24
(ExternalProject: Move inline scripts to separate files, 2022-01-22,
v3.23.0-rc1~101^2) did not account for the possibility that
`CMAKE_CFG_INTDIR` is `$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)`
instead of just the configuration name. Pass the value into the helper
script on the command line so that the native buildsystem placeholders
are evaluated.
Fixes: #23645
Xcode 14 no longer accepts an empty signing identity for macOS.
However, Xcode in general does not accept an ad-hoc signing
identity for iOS. Switch based on the target platform.
Fixes: #23609
Forward `CMAKE_<LANG>_FLAGS` and `CMAKE_<LANG>_FLAGS_DEBUG` from the
calling project into the test project. The set of flags may affect the
availability of IPO support. Since this may change the result of the
check for existing projects, add a policy for compatibility.
This was discovered after commit 5fcadc481e (MSVC: Default to -ZI
instead of /Zi for x86 and x64, 2022-05-24) introduced policy CMP0138 to
switch our default for MSVC's debug info flag. The `-ZI` flag is
incompatible with the `-GL` flag used for IPO, so CMP0138 was reverted
pending future work on an alternative solution. Re-use the CMP0138
policy number for this change to CheckIPOSupported instead.
Fixes: #23607
Revert commit 5fcadc481e (MSVC: Default to -ZI instead of /Zi for x86
and x64, 2022-05-24). The `-ZI` flag is incompatible with the `-GL`
flag used for IPO, and so is not an unconditionally better default.
Revert the change pending future design of a first-class setting for
MSVC debug info format that can be automatically reconciled with IPO
settings.
That commit introduced policy CMP0138, but we already have later policy
numbers used too. Leave placeholder text to avoid policy renumbering.
Issue: #23607, #10189
The guide previously only focused on the find_package() command,
with a bias towards libraries. FetchContent was not mentioned at all.
Reorganise and update the existing content. Add new sections to cover
providing dependencies with FetchContent and dependency providers.
Improve discoverability of the guide by mentioning it at the beginning
of the find_package(), FetchContent and dependency provider docs.
The ExternalProject module has long used the generator-specific
placeholder in the `${CMAKE_CFG_INTDIR}` variable to express per-config
stamp file paths in multi-config generators. Now that most generators
support generator expressions in custom command outputs, we can use
the `$<CONFIG>` genex instead.
In particular, this fixes cross-config `BUILD_BYPRODUCTS` with the Ninja
Multi-Config generator.
Fixes: #23595
It's been a long-standing bug in CMakePrintHelpers that the
cmake_print_properties() function cannot print the SOURCES
property of a requested TARGET, confusing it with a request
to print properties of SOURCES.
We work around this by parsing the arguments in two stages,
so that a SOURCES that comes after the PROPERTIES keyword
is handled differently from a SOURCES that comes before it.
This adds the restriction that the "mode" keyword (TARGETS
SOURCES DIRECTORIES etc...) and its arguments **must** precede
the PROPERTIES keyword and its arguments. In other words:
1. Both of these are now valid and will be interpreted correctly,
whereas previously only the first was, and the second caused
a FATAL_ERROR:
cmake_print_properties(SOURCES foo.c PROPERTIES LANGUAGE)
cmake_print_properties(TARGETS foo PROPERTIES SOURCES)
2. This, OTOH, which used to be valid, no longer is, and will
trigger a FATAL_ERROR:
cmake_print_properties(PROPERTIES LANGUAGE SOURCES foo.c)
Fixes: #14883
The variables `OPENSSL_VERSION_MAJOR`, `OPENSSL_VERSION_MINOR` and
`OPENSSL_VERSION_FIX` are now set to the correct values when using
OpenSSL version >= 3.0.0, which uses a new format.
On macOS monterey, `java -version` returns
```
The operation couldn’t be completed. Unable to locate a Java Runtime.
Please visit http://www.java.com for information on installing Java.
```
which does not match the existing regex. Instead of hitting a fatal error if required,
reset the variable and let FindPackage handle the result.
If `QUIET` is requested, don't print anything if the version query fails. Otherwise, print the message.
Additionally, clean up temporary variables set by the execute_process commands.
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
The macros `cpack_append_variable_set_command` and
`cpack_append_string_variable_set_command` became functions, in order to
support arguments with special characters (e.g. `:`).
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
