Some deployments may not be able to discover the metadata file reliably
(e.g., custom `clang` builds on macOS while using the SDK's stdlib or
distribution bugs). Allow users to force the location so that
compiler-driven detection doesn't have to bend over backwards for
unforeseen bugs.
Although there is no `cl -std:c23` flag, the underlying Clang compiler
does have a C23 mode we can activate by passing `-std=c23` through a
`clang-cl` wrapper flag.
Also port the fix from commit 30139913e9 (VS: Restore support for mixing
C++23 and C in one target with clang-cl, 2024-12-09, v3.31.3~10^2).
Fixes: #27038
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Co-authored-by: Brad King <brad.king@kitware.com>
d592558b8b cmLocalGenerator: Drop no-op link flag placeholder infrastructure
67639002ad Ninja,Makefile: Drop now-unused placeholders from link rule variables
951e4d3f62 Ninja,Makefile: Move builtin linker flags to <LINK_FLAGS> placeholder
6b618c6079 cmLocalGenerator: Clarify MODULE link flags placeholder population
c52a654aa1 cmLocalGenerator: Improve formatting of rule placeholder variable list
37cf9941ed UseEcos: Add missing placeholder in rules to link executables
fa61be5bc4 Embarcadero,OpenWatcom: Clear unused flags for creating shared libraries
124e40947c CMakeCommonLanguageInclude: Do not unset MODULE library flags when empty
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10869
Previously we used separate placeholders for builtin linker flags:
* CMAKE_<LANG>_LINK_FLAGS for EXECUTABLEs
* CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS for SHARED libraries
* CMAKE_SHARED_MODULE_CREATE_<LANG>_FLAGS for MODULE libraries
These are now always replaced by the empty string, so drop them
from our rule variables.
Clear `CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS` since no special
link flags are needed to create a DLL with these toolchains.
Our shared library creation rules do not reference the placeholder,
so this variable was never used. However, we may soon teach the
generators to look it up directly.
This was done by mistake in commit d090159318 (ENH: add support for the
ADSP toolchains for Blackfin, Shark and TigerShark DSPs, patch from
Raphael Cotty, 2007-07-12, v2.6.0~1446), and preserved in the
generalization by commit e9eabb0dcd (ADSP: Configure compiler in
compiler module, 2022-03-24, v3.24.0-rc1~331^2~1). Fix both places.
In commit c54a621b55 (Cray: New platform file for Cray Linux Environment
and PrgEnv, 2015-11-13, v3.5.0-rc1~216^2~1) we populated variable
`CMAKE_STATIC_LIBRARY_LINK_<LANG>_FLAGS`, but we never reference it, and
the generators do not use it. Static libraries are archives, and are
not produced by a linker.
In commit 9e66397c28 (Languages: Add support for Objective-C++,
2019-09-13, v3.16.0-rc1~44^2~2) we set `CMAKE_OBCXX_LINK_FLAGS`.
It was a typo for `CMAKE_OBJCXX_LINK_FLAGS`, and so has not had
any effect.
LLVM/Clang 20, when invoked as `clang++ -E -c ...`, now warns:
warning: argument unused during compilation: '-c'
Drop the unnecessary `-c` flag. Also add a `-w` flag to suppress
warnings so their text is not parsed as predefines.
Pass `-g` to enable debugging, not `-O` for optimizations. This was
probably a typo in commit b50bfc8913 (HIP: Add language to CMake,
2020-08-28, v3.21.0-rc1~66^2~4).
Fixes: #26823
Revert commit b3f1c60aff (MSVC: Use -std:c++23preview flag for C++23
when available, 2025-03-12), except for the VS flag table update.
MSVC documentation states that the flag will be removed in the future
when `-std:c++23` is added. Therefore it is only suitable for manual
specification by end-users.
Issue: #26692
b3f1c60aff MSVC: Use -std:c++23preview flag for C++23 when available
1b4a802413 MSVC: Split C++23 flag selection into dedicated block
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10462
b3f1c60aff MSVC: Use -std:c++23preview flag for C++23 when available
1b4a802413 MSVC: Split C++23 flag selection into dedicated block
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10462
77f71ad4e2 Remove compatibility with CMake versions older than 3.5
fb1bd1d330 CMP0065: Remove support for OLD behavior
d9dd38cccf CMP0064: Remove support for OLD behavior
d88047c329 Remove compatibility with CMake versions older than 3.3
ac1a9cb160 CMP0063: Remove support for OLD behavior
36fffb673a CMP0062: Remove support for OLD behavior
789a7d73d4 CMP0061: Remove support for OLD behavior
3dc19e24cb CMP0060: Remove support for OLD behavior
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10210
Tasking compiler extensions and language standard flags are not tied
together as they are with gcc/clang. Since CMake does not model
granular abstractions for extensions, leave individual extension flags
to the project or user.
Fixes: #26591
fc163f9e43 Tasking: Add support for ASM through the cctc compiler driver
942f0d119b Tasking: Add identification for the tasking assembler
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10163
The Tasking ASM information module was added by commit 94df5b6ef1
(Tasking: Add support for several compiler toolsets, 2022-07-20,
v3.25.0-rc1~133^2). However, it appears to have been left from pattern
following and did not actually work with the Tasking assembler.
Update it to work when running the assembler through the compiler
driver `cctc`, which supports extensions `.asm` and `.src`.
Fixes: #26425
In commit cfa888a6e2 (Clang/CUDA: Add language-wide flags when linking
with compiler driver, 2024-10-07, v3.31.0-rc1~12^2) we added the wrong
placeholder to `CMAKE_CUDA_CREATE_SHARED_LIBRARY` to represent the
language-wide flags. The `<FLAGS>` placeholder is for executables.
The `<LANGUAGE_COMPILE_FLAGS>` placeholder is for shared libraries.
The distinction is for historical reasons.
Fixes: #26563
