It is a normal target, but will end up copying its internals from
another target. Keep track of this state so that such copying can only
occur when intended.
C++ modules are going to introduce a third concept of "synthesized"
targets, so update logic where needed to avoid assuming "not imported?
must be normal".
Also add an accessor method to perform queries against the visibility.
`INTERFACE` targets with C++ modules are basically BMI-only modules. It
is unknown if they will be useful directly (due to ODR of the `module
M;` initializers needing to live in some specific object file). However,
they will be used to attach BMI-only compilations of `IMPORTED` C++
modules.
Since commit f69d1872db (cmGeneratorTarget: Add caches to some
functions, 2022-11-23) we cache the computed link options for a target.
Cache the host and device link options separately.
Add caches to the following cmGeneratorTarget functions in order to
improve performance:
- GetIncludeDirectories
- GetCompileOptions
- GetCompileDefinitions
- GetPrecompileHeaders
- GetLinkOptions
- GetLinkDirectories
5e7c8f44ac Ninja: Restore support for compilers not defining a C++ standard level
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Acked-by: Jaeden Amero <kitware@patater.com>
Acked-by: Martin Kojtal <martin.kojtal@arm.com>
Merge-request: !7896
Since commit 386465bf83 (cmTarget: add support for C++ module fileset
types, 2022-04-08, v3.25.0-rc1~624^2~7), the Ninja generator checks for
C++20 support using logic that requires `CMAKE_<LANG>_STANDARD_DEFAULT`
to be non-empty. On some compilers, such as ARMClang, CMake does not
automatically detect and set default language standards, thus causing
`HaveStandardAvailable` to raise an internal error.
To fix this issue, if `CMAKE_CXX_STANDARD_DEFAULT` is empty, assume all
standards to be supported instead of calling `HaveStandardAvailable`.
This is consistent with how `CompileFeaturesNode::Evaluate` handles this
case.
Fixes: #24146
41f15193e5 VERIFY_INTERFACE_HEADER_SETS: Fall back to global languages
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !7517
41f15193e5 VERIFY_INTERFACE_HEADER_SETS: Fall back to global languages
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !7517
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
