Refactoring in commit 72d116ee68 (GenEx: list oriented genexes use
cmList class, 2023-03-29, v3.27.0-rc1~205^2) accidentally caused
empty elements to be dropped by the `REMOVE_DUPLICATES` genex.
Fix it and add a test case.
Fixes: #25080
This generator expression is the inverse of `LINK_ONLY` and only coveys
usage requirements for the purposes of compilation. Its intended use is
to avoid needing to export targets that do not have link usage
requirements (e.g., header-only libraries) when used by another target.
See: #15415
This generator expression is the inverse of `LINK_ONLY` and only coveys
usage requirements for the purposes of compilation. Its intended use is
to avoid needing to export targets that do not have link usage
requirements (e.g., header-only libraries) when used by another target.
It will also be used to represent private usage requirements on exported
C++ module-containing targets in the future.
Eventually there should be logic to collapse nesting of
`$<COMPILE_ONLY>` and `$<LINK_ONLY>` when generating instances of
either. A TODO is left in the code for this case.
See: #15415
a2c9c4f202 Add test for the new TARGET_RUNTIME_DLL_PATHS genex
aa68de0a27 TARGET_RUNTIME_DLLS: minor refactoring of shared-check.cmake
2ce3d62ffb Help: add documentation for the new TARGET_RUNTIME_DLL_DIRS genex
c351dcd967 TARGET_RUNTIME_DLL_DIRS: add the new genex to cmGeneratorExpressionNode
064c3244da TARGET_RUNTIME_DLLS: fix test for this genex
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Acked-by: Alex <leha-bot@yandex.ru>
Merge-request: !8247
This commit adds handling for a new genex TARGET_RUNTIME_DLL_DIRS to
cmGeneratorExpressionNode. It refactors the code for TARGET_RUNTIME_DLLS
a bit, so that both TARGET_RUNTIME_DLL_DIRS and TARGET_RUNTIME_DLLS
share the implementation to collect all dlls. The new genex
collects the dlls and in a final step puts all the directories
into the result variable (and makes sure there are no duplicates).
Add `Green Hills MULTI` to the list of generators checked for the
`COMPILE_LANGUAGE`, `COMPILE_LANG_AND_ID`, `LINK_LANGUAGE`, and
`LINK_LANG_AND_ID` generator expressions, since these are supported by
the generator.
Fixes: #24262
When evaluating the `$<CONFIG>` genex on an imported target has the
`IMPORTED_CONFIGURATIONS` property set, the current project has a config
that does not match any of those, and no explicit configuration mappings
are defined, fall back to the same configuration as `IMPORTED_LOCATION`.
Fixes: #24222
When `$<TARGET_PROPERTY:tgt,prop>` is used in an `INTERFACE_*` target
property for usage requirements, it may be evaluated in the context of a
dependent target in another directory. Look up the `tgt` name in the
directory of the target whose property holds the expression so that
imported targets isolated to that directory are visible.
Fixes: #24163
Fix the genex from commit 997af2e1a6 (Genex: Add TARGET_BUNDLE_DIR_NAME,
2022-04-14, v3.24.0-rc1~233^2) to use the correct bundle directory
extension for each bundle type.
Fixes: #23683
Allow `cmGlobalGenerator`s to decide `HasKnownObjectFileLocation()` per given
`cmTarget`
- `cmGlobalGenerator::HasKnownObjectFileLocation()` now takes an optional `cmGeneratorTarget`
- `cmTarget::HasKnownObjectFileLocation()` added as a shorthand
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
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
Since commit 2ae72ef74b (Xcode: Enable multi-arch TARGET_OBJECTS genex
in [INTERFACE_]LINK_LIBRARIES, 2021-05-26, v3.21.0-rc1~126^2) the
TARGET_OBJECTS genex, when referenced for linking, is now evaluated with
EvaluateForBuildsystem enabled. This causes the object file paths to be
computed with a buildsystem-specific placeholder for the configuration.
This is normally fine because the placeholder will be evaluated by the
native buildsystem tool using the proper configuration. However, the
Ninja Multi-Config generator's `${CONFIGURATION}` placeholder may not
have the correct value for cross-config object files. Switch back to
using the per-config location of each object file for this generator.
Fixes: #22436
