Use named constants. Regularize comparison patterns. Follow the
approach from commit b9d4db7098 (CompilerId: Clarify C and C++ standard
level detection, 2024-04-02).
Update the list of known versions.
Run the command
cmake -DBOOST_DIR=/path/to/boost_1_85_0 \
-P Utilities/Scripts/BoostScanDeps.cmake
to extract dependencies from the 1.85.0 source tree.
They are the same as 1.84's dependencies, so just update
the version check for warning about newer versions.
Fixes: #25905
4af20bb794 NAG-Fortran: Do not repeat preprocessing with Ninja on Apple platforms
91bb8dd872 NAG-Fortran: Fix MODULE library creation on Apple platforms
e056006116 NAG-Fortran: Tell the Ninja generator how to preprocess Fortran sources
765a611956 NAG-Fortran: Added initial default compilation flags
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9407
Wire up the flags needed to support module libraries built and used with
Swift. We need to pass `-bundle` to the linker when linking module
libraries on Darwin, and we need to pass `-export-dynamic` to the linker
when emitting an executable that exports symbols on Linux. This patch
wires up `CMAKE_SHARED_MODULE_CREATE_Swift_FLAGS` and
`CMAKE_SHARED_MODULE_LOADER_Swift_FLAG` on Darwin, and hooks up
`CMAKE_EXE_EXPORTS_Swift_FLAG` on Linux in order to support passing
things correctly.
We can't expose `CMAKE_EXE_LINKER_FLAGS` to Swift, as it contains flags
that the Swift compiler doesn't recognize, but the other
language-specific variables are safe to expose.
This is needed for C++ modules because `import std` support may differ
based on the standard library implementation. Extract the information as
necessary.
Compilers may implement this by implementing a `_cmake_cxx_import_std`
function which takes the standard version as an argument (e.g., `23`)
and creating a target named `CMake::CXX${std}` that represents how
`import std;` should be represented within CMake.
Thread-local variables are put in the tdata section on AIX / XCOFF [1]. Unfortunately
the ExportImportList script currently doesn't consider this section when looking for
symbols to export.
This results in linking failures in applications (such as LLVM) when building which expect these thread local variables to be exported from their shared libraries.
[1]: https://www.ibm.com/docs/en/aix/7.3?topic=formats-xcoff-object-file-format
Revert commit 6ddf8712cd (CMakePackageConfigHelpers: Use unique variable
name for pkg prefix, 2024-03-30, v3.29.1~8^2). It regressed existing
projects that rely on the undocumented `PACKAGE_PREFIX_DIR` variable in
package configuration files generated by `CMakePackageConfigHelpers`.
Fixes: #25873Fixes: #25885
Issue: #25827
In commit 6e8754c625 (FindJasper: Add IMPORTED target, 2021-10-06,
v3.22.0-rc1~20^2) this property was not set correctly. This was
detected by `CMP0160` because the `IMPORTED` property is read-only.
80a5a86514 GNU: Fix detection of C++ 11 mode in GCC 4.{4,5,6}
c9cc3dc646 PGI: Fix detection of C++ 14/17 modes
7f05d472a2 NVHPC: Fix detection of C++ 20 mode on NVHPC < 22.7
3587579f34 XL/XLClang: Fix detection of C++ 14 mode on Linux
863cde8c19 Intel: Fix detection of C++ 14/17 modes on Linux/macOS
1e774a86d3 Intel: Fix detection of C++ 17/20 modes on Windows
b9d4db7098 CompilerId: Clarify C and C++ standard level detection
ae18811f2e IntelLLVM: Add C standard flags on Windows
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9412
These versions of the compiler have experimental C++11 support and so do
not define `__cplusplus` correctly, but do define a feature macro we can
use to distinguish this mode.
The Intel Classic C++ compiler is based on EDG. It does not always
define `__cplusplus` correctly, but does define feature macros that we
can use to distinguish these modes.
The Intel Classic C++ compiler for Windows does not always define
`_MSVC_LANG` correctly, but does define feature macros that we can use
to distinguish these modes.
