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.
42654cc818 Tests/CXXModules: add tests for modules with include requirements
7217cb78cf Tests/CXXModules: relax line number matching in stderr
b3d1bbbbcc cmExportFileGenerator: relocate include directories for C++ modules
349ff8b080 cmGeneratorTarget: remove not-INTERFACE assertion
681a763425 cmGeneratorTarget: use a character literal
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8838
IMPORTED INTERFACE targets which provide C++ modules may have include
directories that need checked for whether they are system directories or
not. These directories are intended for the module compilation
themselves (which may include headers that module consumers do not need).
* fortran-object-libraries-release:
cmComputeLinkInformation: compute link info for module-using targets
cmGeneratorTarget: support config-independent Fortran source queries
571b5e1f2c cxxmodules: improve error messages for C++ module setup
8b4d32c18b cmStandardLevelResolver: add query for the effective standard level
17ddc4ac76 cmStandardLevelResolver: compare with static string literals
6f1dae2b01 cmStandardLevelResolver: use `cmStrCat` where possible
0d45d40e13 cmStandardLevelResolver: use character literals where possible
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !8755
We need to be able to construct BMIs that will be usable from the client
modules for the target importing the module, so create BMI-only
compilation rules for `IMPORTED` targets to create these BMIs.
