The CMAKE_MSVC_RUNTIME_LIBRARY variable docs mention that it
initializes the MSVC_RUNTIME_LIBRARY target property, but the
property's docs was missing any mention of the variable.
The docs for the CMAKE_VERIFY_INTERFACE_HEADER_SETS variable do
mention that it initializes the property, but the property docs didn't
mention the variable. Add that missing cross-reference.
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
The INTERFACE_LINK_LIBRARIES_DIRECT property can add direct
link dependencies to the target at the head of the dependency chain.
The checks associated with LINK_LIBRARIES_ONLY_TARGETS also apply
to these link items, but the documentation wasn't updated to reflect
this when the INTERFACE_LINK_LIBRARIES_DIRECT support was added.
This is the name of a placeholder used for some documentation in
`Help/prop_tgt/INTERFACE_LINK_LIBRARIES_DIRECT.txt` that is included in
multiple documents. During development iterations, much of the content
was moved to just `Help/prop_tgt/INTERFACE_LINK_LIBRARIES_DIRECT.rst`,
but the placeholder was not correctly replaced by its property name.
These changes restructure the docs to improve readability and flow,
correct grammar and typos, and fix errors and inconsistencies in
some of the examples.
Fixes: #23684
Extend the change from commit b764c7c273 (VS: Add property to turn off
Visual Studio compile batching, 2022-02-07, v3.24.0-rc1~710^2) by
adding a variable to initialize the property on every target.
Issue: #23179Fixes: #23639
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).
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
Add `COMPILE_WARNING_AS_ERROR` target property and supporting
`CMAKE_COMPILE_WARNING_AS_ERROR` variable.
`COMPILE_WARNING_AS_ERROR` is initialized by
`CMAKE_COMPILE_WARNING_AS_ERROR`. It is a boolean variable. If it is
true, it expands to a different flag depending on the compiler such that
any warnings at compile will be treated as errors.
Supports compiler ids that I could find a relevant flag for.
Add a `CMAKE_WATCOM_RUNTIME_LIBRARY` variable to control the
runtime library selection. Add policy CMP0136 to switch to
in place of the old hard-coded default flags.
Fixes: #23178
5fa15ec9f3 Help: Document that target_sources defines [INTERFACE_]HEADER_SETS
c5d4812f20 cmTarget: make HEADER_SETS and INTERFACE_HEADER_SETS read-only
05783b168d cmFileSet: store visibility with the fileset
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7168
There is no reason to allow these properties to be manipulated by user
code. Instead, use the stored visibility on the fileset objects to
derive what these properties should contain.
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
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
Craig Scott