Add a variable to indicate the latest standard known to be supported for
each language:
* `CMAKE_C_STANDARD_LATEST`
* `CMAKE_CXX_STANDARD_LATEST`
* `CMAKE_CUDA_STANDARD_LATEST`
* `CMAKE_HIP_STANDARD_LATEST`
* `CMAKE_OBJC_STANDARD_LATEST`
* `CMAKE_OBJCXX_STANDARD_LATEST`
These variables, more generally referred to as
`CMAKE_<LANG>_STANDARD_LATEST`, are assigned an integer value which
represents the minimum between the latest version of the associated
language standard supported by the current compiler and the latest
version supported by CMake.
Add documentation for these variables in a new page called
`CMAKE_<LANG>_STANDARD_LATEST` was added under the "Variables for
Languages" section of the `cmake-variables(7)` page.
Update each compiler-specific CMake script under
`${CMAKE_ROOT}\Modules\Compiler` to manually define the relevant
`CMAKE_<LANG>_STANDARD_LATEST` variable as necessary. This will
require updating and maintaining as newer compiler versions become
recognized by CMake.
Closes: #25717
Set the requirement for Objective C 23 support for AppleClang to
`11.0.3` in `${CMAKE_ROOT}\Modules\Compiler\AppleClang-OBJC.cmake`.
This is consistent with the requirement for C 23 support as
indicated in `${CMAKE_ROOT}\Modules\Compiler\AppleClang-C.cmake`.
Unset irrelevant compile option variables in the following scripts:
* `${CMAKE_ROOT}\Modules\Compiler\ARMClang-C.cmake`
* `${CMAKE_ROOT}\Modules\Compiler\TIClang-C.cmake`
* `${CMAKE_ROOT}\Modules\Compiler\TIClang-CXX.cmake`
These scripts all include either
`${CMAKE_ROOT}\Modules\Compiler\Clang-C.cmake` or
`${CMAKE_ROOT}\Modules\Compiler\Clang-CXX.cmake`, and those scripts
will set various compile option variables based on what the
standard version of Clang supports. However, these do not
necessarily apply to ARMClang and TIClang. This commit thus
explicitly unsets all of the compile option variables which are not
manually defined for these compilers.
Fat LTO objects contain both traditional object code and the LTO bitcode
IR, but the GNU compiler does not support them on Apple platforms.
A compile error is raised when `-f[no-]fat-lto-objects` flags are used,
so avoid them.
This also implies that static Fortran libraries cannot be built with IPO.
Fixes: #25931
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
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.
588371d2d5 Modules: Rename CMakeDetermine{CompileFeatures -> CompilerSupport}
4d27ef55bd Modules: Factor out helpers for GNU language standard flags
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9366
Add the following macros to `${CMAKE_ROOT}\Modules\Compiler\GNU.cmake`:
* `__compiler_gnu_c_standards()`
* `__compiler_gnu_cxx_standards()`
These macros are used to define the
`CMAKE_<LANG><STANDARD>_STANDARD_COMPILE_OPTION` and
`CMAKE_<LANG><STANDARD>_EXTENSION_COMPILE_OPTION` variables for C-
and C++-based languages for GCC. The macros are similar to the
existing `__compiler_clang_cxx_standards()` macro found in
`${CMAKE_ROOT}\Modules\Compiler\Clang.cmake`.
In commit 8218aed118 (IntelLLVM: support marking include paths as SYSTEM
directories, 2023-08-15, v3.29.0-rc1~81^2) this flag was added for the C
and C++ compilers, but was accidentally added for Fortran too. Remove
it for the latter, as it is unsupported.
Issue: #25807
When cross-compiling, `clang-scan-deps` needs help to find the correct
location of core headers such as `stddef.h`. Always determine this path
and pass it when available.
Fixes: #25590
Apply the fix from commit 1ec6485c6a (Support duplicate object names in
large archives, 2014-04-16, v3.1.0-rc1~629^2) to the IPO-specific
archiving rules. Use "quick append" instead of "replace".
Fixes: #25675
Issue: #14874
Add TIClang compiler ID and support in compiler modules. Update
documentation. Add rudimentary RunCMake test for TIClang to test
basic functionality.
Fixes: #24619
When `clang-scan-deps` fails to scan (e.g., bad source syntax, junk
flags, etc.), the redirection unconditionally updates the file. If this
fails, the `.ddi` file timestamp is updated. If the state is then
reverted (e.g., the command line returns to the state of the last
successful build), the updated file is not useful, but `ninja` does not
rerun because:
- the command hash matches the last successful run
- the output file is newer than its inputs
However, since the `.ddi` file has been updated with bogus contents from
a failed scan, collation fails as the `rules` array is empty (or
incomplete from a batch scan).
If `clang-scan-deps` were properly aware of its output file, it could
use this to not write the file if any inner scan fails. Requested in
https://github.com/llvm/llvm-project/issues/72875.
See: https://github.com/llvm/llvm-project/issues/72875Fixes: #25429
Since commit a66004bee0 (Honor CMAKE_<LANG>_FLAGS[_<CONFIG>]_INIT set in
toolchain files, 2016-07-05, v3.7.0-rc1~392^2) we've accidentally been
adding extra optimization flags instead of replacing unwanted flags.
Fixes: #25434
