11adb3b7ae Linker/Windows-MSVC: check for a non-empty linker version
32c12e6901 Modules/CMakeLANGCompiler.cmake.in: quote linker version and frontend variant
31946711d3 CMakeDetermineCompilerSupport: support skipping compiler feature checks
71d908010f Modules/DetermineCompiler: support skipping compiler checks
e267321f93 Modules/DetermineCompiler: avoid the cache for ABI compilations
94f4c64461 Tests/RunCMake/ToolchainSkipsChecks: add tests for skipping compiler checks
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11917
To ensure that the correct linker is selected (host or device link),
use the generic driver (i.e. lld) rather than a specific linker (like lld-link).
Fixes: #27826
We detect the architecture once and store it in `_PellesC_ARCH`.
Do not unset it after the first language is enabled.
This fixes commit bc51518821 (PellesC: Compile for architecture matching
LIB environment variable, 2026-05-07) by removing lines left from an
earlier draft of the change.
Issue: #21536
Reported-by: Serguei E. Leontiev <leo@sai.msu.ru>
Swift supports CodeView/PDB for Windows (with active development ongoing
to make it the default). It is currently usable but does not have the
same fidelity as DWARF, but can be sufficient for many use cases. The
user is able to control this via flags. Wire up the necessary support to
allow `TARGET_PDB_FILE` to be used with Swift/Swift-only targets.
Extend commit 2b2344b412 (MSVC: Add abstraction for runtime checks,
2025-01-22, v4.0.0-rc1~92^2) to cover LLVMFlang. This is necessary
to configure with CMP0184's NEW behavior.
We already do this for MSVC and MinGW. The linker ignores them
if no symbols are needed.
Issue: #21536
Co-authored-by: Serguei E. Leontiev <leo@sai.msu.ru>
Prior to CMake 4.2.0, projects using the EMSDK's toolchain file while
also enabling `TARGET_SUPPORTS_SHARED_LIBS` would link shared libraries
using our default `-shared` flag plus whatever `-sSIDE_MODULE` flag
the project added, if any. CMake 4.2.0 introduced builtin Emscripten
support, but since commit d361bf365e (Emscripten: Drop hard-coded
-sMAIN_MODULE and -sSIDE_MODULE flags, 2025-09-18, v4.2.0-rc1~146^2)
we still leave it to projects to add Emscripten-specific flags needed
to link shared libraries.
Restore the pre-4.2 behavior of adding the `-shared` flag. In
particular, this is needed for upcoming Emscripten support for real
shared libraries.
Issue: #27240
The Pelles C compiler requires MS extensions to support `__declspec`
and other constructs needed to use Windows APIs. Unfortunately the
flag also disables standard definitions, so restore them.
Issue: #21536
Co-authored-by: Serguei E. Leontiev <leo@sai.msu.ru>
The Pelles C compiler does not support ASM, and the `poasm` assembler
uses a distinct syntax. Add a dedicated language as we do for similar
cases from other vendors. Leave documentation commented out for now
because the PellesC toolchain support in general is not yet documented.
Fixes: #27758
Issue: #21536
Co-authored-by: Serguei E. Leontiev <leo@sai.msu.ru>
The PellesC toolchain provides a `porc` tool to compile them.
Note that `polib` fails to archive resource files (`.res`):
POLIB: fatal error: An internal error occurred
Turn off the static library part of the VSResource test.
Issue: #21536
Inspired-by: Serguei E. Leontiev <leo@sai.msu.ru>
Xcode 26.4's iPhoneOS SDK advertises arm64e (not arm64) in
libSystem.tbd. After stripping the platform suffix, the arch list
contains arm64e, which doesn't match when CMAKE_OSX_ARCHITECTURES
includes arm64. As a result, arm64 falls through to the simulator
SDK, silently breaking iOS device builds.
Since arm64e is a superset of arm64 (all arm64e devices run arm64
binaries), we now fall back to checking for arm64e when arm64 is
not found in an SDK's architecture list.
Add bare minimum functionality to compile C code and link on Windows.
Explicitly label tests that are expected to work with `CFLAGS=-Ze`.
Leave out documentation for now because this is not usable in general.
Issue: #21536
Inspired-by: Serguei E. Leontiev <leo@sai.msu.ru>
Previously, `CMAKE_<LANG>_LINK_FLAGS` was an undocumented variable used
for linking executables only. Re-spell that variable mirroring the
existing spellings for shared and module libraries, and add policy
CMP0210 to preserve compatibility.
Then, repurpose `CMAKE_<LANG>_LINK_FLAGS` to provide a variable to be
used for per-language link flags for all target types, along with a
per-configuration variant. These are added to the `<LINK_FLAGS>` rule
placeholder in the generators.
Fixes: #21934
Relates: #25620
Co-authored-by: Brad King <brad.king@kitware.com>
In commit a90d2a9eed (IntelLLVM: Add support for Intel LLVM-based
compilers, 2020-11-02, v3.20.0-rc1~89^2~20) we added a `set()` that is
immediately followed by another `set()` of the same variable. Remove
the former.
Fixes: #27019
In commit 96d9b94a98 (Emscripten: Add platform modules, 2025-05-16,
v4.2.0-rc1~607^2~3) this flag was added as part of an attempt to support
shared libraries without requiring projects to set much themselves. That
attempt was reverted by commit d361bf365e (Emscripten: Drop hard-coded
-sMAIN_MODULE and -sSIDE_MODULE flags, 2025-09-18, v4.2.0-rc1~146^2).
Also avoid hard-coding `-fPIC`. `POSITION_INDEPENDENT_CODE` is already
enabled for shared library targets. Projects can enable it themselves
where `-fPIC` is needed outside of shared libraries.
Fixes: #27424
Issue: #27240
Since commit 96d9b94a98 (Emscripten: Add platform modules, 2025-05-16,
v4.2.0-rc1~607^2~3), compilation command-lines for Emscripten place
`-c <SOURCE>` before all the flags. Restore the original order.
Fixes: #27404
Extend commit e78abf94e3 (VS/Android: Use ApplicationTypeRevision 3.0 in
VS2022, 2023-04-21, v3.27.0-rc1~165^2~4) to cover VS 2026 too. This was
missed in commit 3392b371e2 (VS: Add Visual Studio 18 2026 generator,
2025-08-20, v4.2.0-rc1~165^2~1).
