Teach the `$<TARGET_PROPERTY:...>` generator expression to check for a
new `TRANSITIVE_COMPILE_PROPERTIES` property in the target's link
closure to enable transitive evaluation of named properties through
the link closure, excluding entries guarded by `$<LINK_ONLY:...>`.
Issue: #20416
142a85f9c1 cxxmodules: use filesystem-safe export names in filenames
4452d41488 cmGeneratorTarget: add method to get a filesystem-safe export name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9474
Include the name of the `EXPORT` in the filename when generating export
information for C++ modules. This allows the same directory to be used
for multiple sets of C++ module-using targets.
For `export(TARGETS)` uses, generate a name based on the hash of the
concatenation of the target names involved with the `export()` call.
Fixes: #25609
When consuming exported targets which contain C++ modules, the consuming
project must be able to recompile BMI files using the original target's
flags. This is because a module source may use some private target usage
requirement but not want to propagate it to consumers. To facilitate
this, export the private information as necessary for consumers to be
able to perform the BMI compilations.
When install(TARGETS) and install(EXPORT) were called with file sets
and an absolute CMAKE_INSTALL_INCLUDEDIR, "${_IMPORT_PREFIX}/" was
still being prepended to the base directory and files, resulting in
incorrect paths. Don't prepend this when absolute paths are used.
Fixes: #25010
Calling `install(EXPORT)` with the `CXX_MODULES_DIRECTORY` parameter
leads to installation rules being generated which `include()` CMake
scripts that set the `IMPORTED_CXX_MODULES_[CONFIG]` target property for
relevant targets. However, these scripts don't get generated for
targets in an export set which don't have any C++20 modules. When the
installation rules attempt to `include()` the missing scripts, the
install fails.
Co-authored-by: Brad King <brad.king@kitware.com>
Add this target property to specify macro names that propagate to
dependents as `AUTOMOC_MACRO_NAMES`. The dependents will automatically
generate MOC files for source files that contain the inherited macro
names.
Co-Authored-By: Craig Scott <craig.scott@crascit.com>
Fixes: #19679
iOS/tvOS app bundles are flat and do not include the `Contents/MacOS/`
layers, so they should not be in the `IMPORTED_LOCATION`. Use the same
logic that commit 34f5ef564a (iOS: Fix App Bundle layout, 2015-12-10,
v3.5.0-rc1~129^2~1) added for the installation layout.
Fixes: #23963
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).
In commit 55e4753bbb (Refactor cmTargetExport removing
InterfaceIncludeDirecories, 2021-07-20, v3.22.0-rc1~337^2~1) the storage
of `INCLUDES DESTINATION` was moved into each target. However, a target
may be installed in multiple exports, and their `INCLUDES DESTINATION`
should not be mixed.
Convert the IncludeDirectoriesEntries vector to a map and modify access
function to store the directories lists with respect to cmExportTarget
object. This fixes error when the same target is exported more than once
via different exports and each for consequent export its include
directories list grows. Add a test for this case.
Fixes: #23183
To handle safely the values used by CMake variables and properties,
introduce the class cmProp as a replacement from the simple pointer
to std::string instance.
Update the change from commit 64690f6df0 (export: Do not fail generation
for namelink-only case, 2020-10-09, v3.19.0-rc1~7^2) to also handle
separate namelink-only and namelink-skip calls.
Fixes: #21529
This was accidentally left out of commit 0467a2f91b (PCH: add
PRECOMPILE_HEADERS to special properties, 2015-03-12). Also add a test
case for `install(EXPORT)` and `export()` propagation of precompiled
headers.
Fixes: #19741
This patch is generated by a python script that uses regular expressions to
search for string concatenation patterns of the kind
```
std::string str = <ARG0>;
str += <ARG1>;
str += <ARG2>;
...
```
and replaces them with a single `cmStrCat` call
```
std::string str = cmStrCat(<ARG0>, <ARG1>, <ARG2>, ...);
```
If any `<ARGX>` is itself a concatenated string of the kind
```
a + b + c + ...;
```
then `<ARGX>` is split into multiple arguments for the `cmStrCat` call.
If there's a sequence of literals in the `<ARGX>`, then all literals in the
sequence are concatenated and merged into a single literal argument for
the `cmStrCat` call.
Single character strings are converted to single char arguments for
the `cmStrCat` call.
`std::to_string(...)` wrappings are removed from `cmStrCat` arguments,
because it supports numeric types as well as string types.
`arg.substr(x)` arguments to `cmStrCat` are replaced with
`cm::string_view(arg).substr(x)`
Following commit 49cfd390 (cmExportBuildFileGenerator: improve error
message, 2019-06-26), improve the error message related to installed
export sets by referencing the files which contain the exported target
ambiguously.
Enables the clang-tidy test performance-inefficient-string-concatenation
and replaces all inefficient string concatenations with `cmStrCat`.
Closes: #19555
