If a target doesn't have any source files, fall back to the global
list of enabled languages to determine the language of the header
file to verify.
Fixes: #23774
07bc3b07ec gitlab-ci: test C++ modules using GCC
1b2270aa4e ci: add a Docker image to test out C++ modules with GCC
8c5a53096a Tests/RunCMake/CXXModules: add module-using examples
4151547e2f cmGlobalNinjaGenerator: use `cmModuleMapper` implementation
b43bdaff3c cmCxxModuleMapper: implement support for GCC's module map format
02d0f0e752 cmCxxModuleMapper: add source to handle module mapper contents
a046a45aad cmGlobalNinjaGenerator: add a TODO for header units
386465bf83 cmTarget: add support for C++ module fileset types
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !7369
C++ modules have two variants which are of importance to CMake:
- `CXX_MODULES`: interface modules (those using `export module M;`,
`export module M:part;`, or `module M:internal_part;`)
- `CXX_MODULE_HEADER_UNITS`: importable header units
Creating C++ modules or partitions are *not* supported in any other
source listing. This is because the source files must be installed (so
their scope matters), but not part of usage requirements (what it means
for a module source to be injected into a consumer is not clear at this
moment). Due to the way `FILE_SET` works with scopes, they are a perfect
fit as long as `INTERFACE` is not allowed (which it is not).
Rename the booleans 's_ErrorOccured' and 's_FatalErrorOccured' to
's_ErrorOccurred' and 's_FatalErrorOccurred', respectively.
Rename the getters and setters to 'Get[Fatal]ErrorOccurred' and
'Set[Fatal]ErrorOccurred', and fix all uses across the codebase.
Add a new property, INTERFACE_HEADER_SETS_TO_VERIFY, which contains
a list of header sets that should be verified by
VERIFY_INTERFACE_HEADER_SETS.
Fixes: #23522
If an INTERFACE library has HEADER_SETS, and its header sets contain
files generated by a custom command, the library needs to participate in
the buildsystem so that the files will be generated.
Fixes: #23422
Previously we always used content guarded by `$<LINK_ONLY:...>`
in `LINK_LIBRARIES`, even when evaluating for non-linking usage
requirements. Add a policy to honor `LINK_ONLY` in `LINK_LIBRARIES`
the same way we already do in `INTERFACE_LINK_LIBRARIES`.
In commit f3ad061858 (Add usage requirements to update direct link
dependencies, 2022-01-12, v3.23.0-rc1~44^2), we evaluated the transitive
closure of `INTERFACE_LINK_LIBRARIES` as a non-linking usage requirement.
That left out `INTERFACE_LINK_LIBRARIES_DIRECT` link dependencies that
appear behind private dependencies of a static library, guarded by the
`$<LINK_ONLY:...>` generator expression. At the time, that decision was
intentional, in order to prevent arbitrary usage requirements from
leaking out of `PRIVATE` dependencies.
Since then, we've revised evaluation of `LINK_LIBRARIES` to distinguish
between collecting link dependencies and other usage requirements. Use
that information when following `INTERFACE_LINK_LIBRARIES` to collect
the matching kind of requirements from `INTERFACE_LINK_LIBRARIES_DIRECT`.
Fixes: #22496
We evaluate `LINK_LIBRARIES` and `INTERFACE_LINK_LIBRARIES` for two purposes:
* Constructing the link line.
* Collecting usage requirements.
We evaluate `INTERFACE_LINK_LIBRARIES` separately for each purpose in
order to support the `$<LINK_ONLY:...>` generator expression used to
express private link dependencies of a static library. Previously we
only evaluated `LINK_LIBRARIES` for linking, and used that result for
collecting usage requirements too. Therefore `$<LINK_ONLY:...>` does
not work in `LINK_LIBRARIES`.
With the introduction of `INTERFACE_LINK_LIBRARIES_DIRECT`, evaluation
of `LINK_LIBRARIES` now needs to distinguish these two cases in order to
honor link dependencies encountered through `$<LINK_ONLY:...>` without
also exposing other usage requirements through private dependencies of a
static library. Revise internal infrastructure to distinguish the two
cases when evaluating `LINK_LIBRARIES`. Make the information available
in code paths for `INTERFACE_LINK_LIBRARIES_DIRECT` and `LINK_ONLY`.
Defer actually using the information to later commits.
Issue: #22496
Revert commit f3ad061858 (Add usage requirements to update direct link
dependencies, 2022-01-12, v3.23.0-rc1~44^2) and the property storage
updates in its predecessor commit 193a999cd5 (cmTarget: Add
INTERFACE_LINK_LIBRARIES_DIRECT{,_EXCLUDE} backtrace storage,
2022-01-06, v3.23.0-rc1~44^2~1) from the 3.23 release branch.
After initial experience using the feature in practice, additional
design considerations have been raised for discussion in the original
issue. To avoid rushing this for the 3.23 series, we've decided to
revert the feature for now so it can be revised for a future release.
Issue: #22496
CUDA 11.6 added the `nvcc -arch=native` flag to automatically compile
for the host GPUs' architectures. Add support for specifying this
special `native` value in `CMAKE_CUDA_ARCHITECTURES` and
`CUDA_ARCHITECTURES`. During the compiler ABI detection step,
detect the native architectures so we can pass them explicitly
when using Clang or older versions of nvcc.
Fixes: #22375
Refactor the logic checking `CMAKE_CUDA_ARCHITECTURES` special values.
Switch on the value first, and then make other decisions for each case.
This makes room for other special values to be added later.
Since commit 8f64df0a7c (CUDA: Generic all and all-major support,
2021-12-19, v3.23.0-rc1~23^2), setting `CUDA_ARCHITECTURES` to a value
other than `all` or `all-major` is ignored with NVCC 11.5+. Fix the
logic to return early only when actually using an "all" value.
Fixes: #23243
This generator expression offers the capability, for the link step, to
decorate libraries with prefix/suffix flags and/or adding any specific flag for each
library.
Fixes: #22812, #18751, #20078, #22703
Commit 14d8a276 (CUDA: Support nvcc 11.5 new -arch=all|all-major flags,
2021-08-17) added all and all-major options to CUDA_ARCHITECTURES. These are
fairly generic and likely to see real-world use by distributors. Thus it's
desirable to support these also for Clang and older NVCC versions.
The supported architectures are dependent on the toolkit version. We determine
the toolkit version prior to compiler detection. For NVCC we get the version
from the vendor identification output, but for Clang we need to invoke NVCC
separately.
The architecture information is mostly based on the Wikipedia list with the
earliest supported version being CUDA 7.0. This could be documented and
expanded in the future to allow projects to query CUDA toolkit version and
architecture information.
For Clang we additionally constrain based on its support.
Additionally the architecture mismatch detection logic is fixed, improved and
updated for generic support:
* Commit 01428c55 (CUDA: Fail fast if CMAKE_CUDA_ARCHITECTURES doesn't work
during detection, 2020-08-29) enabled CMAKE_CUDA_COMPILER_ID_REQUIRE_SUCCESS
if CMAKE_CUDA_ARCHITECTURES is specified. This results in
CMakeDetermineCompilerID.cmake printing the compiler error and our code for
presenting the mismatch in a user-friendly way being useless. The custom
logic seems preferable so go back to not enabling it.
* Commit 14d8a276 (CUDA: Support nvcc 11.5 new -arch=all|all-major flags,
2021-08-17) tried to support CMP0054 but forgot to add x to the interpolated
result. Thus the conditions would always evaluate to false. This is fixed as
a byproduct of removing NVIDIA specific checks, improving the error message
and replacing architectures_mode with a simpler architectures_explicit.
Visual Studio support omits testing the flags during detection due to
complexities in determining the toolkit version when using it.
A long-term proper implementation would be #23161.
Implements #22860.
f3ad061858 Add usage requirements to update direct link dependencies
193a999cd5 cmTarget: Add INTERFACE_LINK_LIBRARIES_DIRECT{,_EXCLUDE} backtrace storage
22d5427aa6 cmGeneratorTarget: Add LookupLinkItem option to consider own target name
f3d2eab36a cmGeneratorTarget: Fix link interface caching of partial results
d75ab9d066 cmGeneratorTarget: Clarify CMP0022 logic in ComputeLinkInterfaceLibraries
f3e9e03fe0 cmGeneratorTarget: Simplify CMP0022 warning check
216aa14997 cmGeneratorTarget: Return early from ExpandLinkItems with no items
1bc98371d1 Tests: Remove unnecessary policy setting from ObjectLibrary test
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6886
Link line construction starts with `LINK_LIBRARIES` and appends
dependencies from the transitive closure of `INTERFACE_LINK_LIBRARIES`.
Only the entries of `LINK_LIBRARIES` are considered direct link
dependencies. In some advanced use cases, particularly involving static
libraries and static plugins, usage requirements need to update the list
of direct link dependencies. This may mean adding new items, removing
existing items, or both.
Add target properties to encode these usage requirements:
* INTERFACE_LINK_LIBRARIES_DIRECT
* INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE
Fixes: #22496
`GetLinkInterface` and `GetLinkInterfaceLibraries` cache their results
to avoid repeating work. In the case that the result does not depend on
the "head" target, they re-use results computed from the first call with
any "head" target. However, if `GetLinkInterfaceLibraries` is called
first, then not all of the link interface is populated. If
`GetLinkInterface` is later called, it needs to finish populating the
link interface even if a partially completed interface was cached.
Follow up commit 1d709ea2f5 (cmGeneratorTarget: Propagate backtraces
from INTERFACE_LINK_LIBRARIES, 2021-12-15), which made the logic a bit
more complicated due to having backtraces for CMP0022 NEW behavior.
Since commit 1d709ea2f5 (cmGeneratorTarget: Propagate backtraces from
INTERFACE_LINK_LIBRARIES, 2021-12-15) we can use the special storage of
the property directly.
On platforms using `CMAKE_LINK_PCH`, the implementation of
`PRECOMPILE_HEADERS_REUSE_FROM`, when re-using the PCH from one object
library in another, adds a PCH object file to the link interface.
Clear any cached link interface to ensure it is used.
The only purpose of `cmLinkImplItem`'s `FromGenex` member is to decide
whether to check CMP0027. That won't be needed for link items added by
new interfaces in the future. Clarify the name to indicate that we do
not always need to know if the item came from a generator expression.
0eea32a376 VS: Add DOTNET_SDK property to generate SDK-style C# projects
a450cc9533 VS: Set ResolveNugetPackages to false for ALL_BUILD and ZERO_CHECK
fa76e5d194 cmVisualStudio10TargetGenerator: Factor out helper for classic MSBuild project
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6634
Changes in cmVisualStudio10TargetGenerator::Generate to write .Net
SDK-style project for VS generators VS 19 and above. Also adds
documentation and tests.
Issue: #20227
