For `import std;` support, CMake needs to know the standard library
involved in order to ensure that the right target is linked. Afterwards,
the created synthetic targets need their target compile features
computed.
In commit 6942234bf5 (VERIFY_INTERFACE_HEADER_SETS: Add IWYU pragma:
associated to verification file, 2022-10-07, v3.25.0-rc1~22^2) the
comment was added as a C++-style comment. The feature works in C too,
so use a C-style comment.
5261af9424 cmGeneratorTarget: store synthetic targets in its cache
e0633a9517 Tests/CXXModules: add a test importing from a `Ninja` install
150d7dbd68 Tests/CXXModules: support building a project with `Ninja`
e48e5e5506 Tests/CXXModules: document `CMake_TEST_MODULE_COMPILATION` items
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9263
In commit 878ae03832 (macOS: IMPORTED framework: Honor SYSTEM target
property in all cases, 2023-08-27, v3.28.0-rc1~162^2) we broke support
for `IMPORTED_LOCATION_<CONFIG>` without `IMPORTED_CONFIGURATIONS`.
Previously it worked if the importing project's configurations match the
set of `IMPORTED_LOCATION_<CONFIG>` properties set. Fix that case.
Fixes: #25506
Issue: #25515
Tell users what generators *do* support C++ modules. Report the current
generator to make clear it is not one of those supporting modules.
Also clarify the purpose of the existing documentation references.
This will be eventually be used to inform the collator of this
information so that Fortran modules provided by the resulting objects
can also be used as intended.
This avoids having to do manual "is already present" checks. The order
the targets are processed does not need to be preserved because the
resulting `languages` result is already a `set`.
Since commit b1c3ae33ea (cmTarget: Short-circuit language computation if
context independent., 2014-04-09, v3.1.0-rc1~669^2~1) we've tried to
avoid repeating computation of the list of sources for a target for
every configuration in the case that a per-config source (or object
library) contributes zero sources. However, it is possible that an
entry contributes zero sources in the first configuration processed but
at least one source in other configurations.
Fixes: #25400
1f507580a1 cmGlobalGenerator: give context about module queries
889aa0354a CMP0155: ignore scanning for sources if no scanner is available
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !8925
This allows for a more graceful transition for projects using C++20
without scanner support (e.g., Clang 15 or GCC 13). While newer
compilers will (needlessly) scan, it allows C++20-using projects to use
older compilers without having to set `CMAKE_CXX_SCAN_FOR_MODULES` to
support newer CMake minimum versions.
Fixes: #25357
Offer the capability, through variable `CMAKE_LINKER_TYPE`, as well as
the target property `LINKER_TYPE` to specify which linker must be used.
The implementation of this capability is specified by variables specific
to the language and linker type: `CMAKE_<LANG>_USING_LINKER_<TYPE>`.
Some definitions are provided as part of `CMake`.
For example, to select the `LLVM` linker rather than the standard one,
the type `LLD` should be specified through the variable `CMAKE_LINKER_TYPE`.
And, on `Apple`, `Linux` and some environments on `Windows`, the variable
`CMAKE_<LANG>_USING_LINKER_LLD` has value `-fuse-ld=lld`. And for `Windows`
environments based on `MSVC`, where the linker is used directly, the tool
`lld-link.exe` will be used rather than `link.exe`.
Fixes: #19174, #24254, #24990
With CMP0155 NEW behavior, we scan C++ sources in targets using C++ 20,
i.e., in which the `cxx_std_20` feature is available. However, our
check for C++ feature availability may incorrectly succeed in two cases:
* MSVC versions from VS 2013 do not model C++ standard levels,
so we assume all features are available as a heuristic to let
projects at least try compiling with them.
* During ABI detection the `CMAKE_CXX20_COMPILE_FEATURES` variable is not
populated so we assume all features are available, knowing that our
ABI detection project does not need them.
For purposes of detecting targets using C++ 20, we do not want to assume
`cxx_std_20` is available, so verify that we really know it is.
Now that scanning support is no longer experimental, the logic for
whether or not to scan C++ 20 sources is now important because all
projects are now exposted to the logic. Make the scanning rules explicit
in the documentation and rework the queries to localize all of the
associated logic.
A policy to handle the ultimate fallback logic will be implemented in a
following commit.
