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.
On most platforms we create shared libraries with `-shared` by default,
but on AIX we add `-Wl,-bnoipath` before the default is applied.
Explicitly specify `-shared` for LLVMFlang instead.
Also add compilation flags for position-independent code.
Fixes: #27818
Add `SamePatchVersion`, `SameFullVersion`, and `SemanticVersion`
support.
Document `ExactVersion` as deprecated in favor of the clearer
`SamePatchVersion`/`SameFullVersion` names.
Closes: #18060
713f4b76ee PellesC: Add C standard levels for Pelles C versions 9 through 12
1f5c9a31f4 PellesC: Remove UTF-8 BOM from test .asm files
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12059
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
Introduce the capability to use the Clang Source code coverage capability
to generate coverage information for a submission to CDash.
This handler will:
* Recursively glob the binary directory for coverage files (`*.profdata`)
* Use the `llvm-profdata` tool to merge all found files into a single
`default.profdata` file
* Recursively glob the binary directory for .o files
* Use the `llvm-cov export` capability to parse the coverage information
found for each object file
Since the coverage information contains branch coverage, add new attributes
to the CoverageLog Line object to capture the number of branches that are
covered and uncovered
See documentation page here
https://clang.llvm.org/docs/SourceBasedCodeCoverage.html
The path-detection routine which sets a default value for
'CMAKE_CXX_STDLIB_MODULES_JSON' is too strict. If the variable is
already set then no additional detection is needed by cmake.
This is relevant when compiling with clang and linking against
Microsoft's STL.
a79ac015c6 ctest: Merge llvm-cov's .profraw files into a .profdata file for each test
5494697ed1 Tests: Add case for llvm-cov usage by ctest command line modes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12007
Update the list of known versions.
Run the command
cmake -DBOOST_DIR=/path/to/boost_1_91_0 \
-P Utilities/Scripts/BoostScanDeps.cmake
to extract dependencies from the 1.91.0 source tree.
Dependencies differ from 1.90:
* Boost.Iostreams no longer depends on Boost.Regex
* Boost.Log no longer depends on Boost.Regex
Fixes: #27803
If the CTEST_TEST_COVERAGE_TOOL is set to LLVM-COV, use the
`llvm-profdata --merge` functionality to collect the `.profraw` files
generated by running each test into a combined `.profdata` file.
This is the file that could be used to parse or display coverage
information for each test.
Issue: #26932
Significant changes on the next major version of the IAR compiler
required some changes in CMake:
- __IAR_COMPILERBASE__ offers a fine grained versioning option
in comparisom with __IAR_SYSTEMS_ICC__, which only referred
to the IAR internal platform version.
- C++20 Language support added for Arm (v10.10.1+), where libc++
is used by default.
3e2d51e823 ASM_NASM: Detect 32-bit object formats from C or C++ target architecture
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12026
Capture `execute_process` calls' `RESULT_VARIABLE`.
We don't actually need to check the result as we presume the existing
logic is already adequate, and sometimes programs return non-zero values
as result of valid query. I.e. this is a "safe" way to broadly protect
these scripts.
Issue: #27782
Move the `<FLAGS>` placeholder to after our builtin `-f` format flag.
This ensures user-specified flags take precedence, as NASM uses
the last occurrence of the `-f` argument.
Issue: #27797
65fbe16e16 NAG Fortran: Use `-xldarg @` to pass response files to the linker
6dc46638f4 NAG Fortran: Fix response file flag for creating archives
b53d3c7cc1 Makefiles: Make logic enabling CUDA device link response files more specific
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !12013
Since commit db76876db5 (Modules: Use new SOURCES_FROM_* try_compile
(1/2), 2022-09-26, v3.25.0-rc1~74^2~1) the variable containing the F90
code was named incorrectly. Thus the compilation test was performed on
an empty source file.
The `nagfor` compiler driver does not invoke the linker directly.
Instead it runs the system C compiler driver, which then invokes the
linker. Passing `@` to NAG Fortran expands the response file before
it reaches the linker, which might lead to too long linker lines.
`-Wl,@`, used since commit 10d6c3a635 (NAG: Pass response files
through front-end to the linker, 2018-08-01, v3.13.0-rc1~244^2), can
lead to wrong placement of the response file on the linker line and
doesn't work at all when the response file is the only object file
passed to the NAG Fortran frontend.
Instead use `-xldarg @` to pass a response file through to the linker
without any intermediate expansion. However, the response file
generated by Ninja can contain flags meant for the compiler driver,
so we need to disable response files for these flags altogether.
Fixes: #23577
Since commit 10d6c3a635 (NAG: Pass response files through front-end to
the linker, 2018-08-01, v3.13.0-rc1~244^2) we use `-Wl,@` instead of `@`
in order to pass the response file through the `nagfor` compiler driver
to the linker. However, this is not needed for the archiver. Create
a separate rule variable so we can use different response file flags
for archiving and linking.
Issue: #23577
12e6c14e69 PellesC: Add default -Ze flag to support compilation against Windows APIs
9db2cf5429 PellesC: Add default compilation and link flags
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !12000
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>
Brad King
Saleem Abdulrasool
Daniele E. Domenichelli
Kyle Edwards
Joseph Snyder
yacoub hossain
Marcel Laverdet
Felipe Torrezan
Robert Maynard
scivision
St Rangeset
Simon Maertens
Ben Boeckel