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
Only generate a graph dependency between a custom command and
a target when the custom command queries for the file path
of an artifact of the target.
This makes generator expressions such as `TARGET_FILE_DIR`
behave the same way as `TARGET_PROPERTY` which never generated
a graph dependency.
When genex $<TARGET_PROPERTY:...> for properties like INCLUDE_DIRECTORIES
is evaluated as part of add_custom_command or add_custom_target,
genex $<COMPILE_LANGUAGE> and $<COMPLIE_LANG_AND_ID> should be supported.
Fixes: #20926
These generator expressions can only be used in link options properties.
These expressions return the arguments respectively for device and host link
step, otherwise return an empty string.
Add entries in Modules and Modules/Platform to support
Objective-C++ compiler determination and identification.
Add Modules to check Objective-C++ compiler flags, source
compilations, program checks, etc...
Use OBJCXX as the designator of the language, eg:
project(foo OBJCXX)
Add various tests for Objective-C++ language features. Add
tests to preserve C++ handling of .M and .mm files when
Objective-C++ is not a configured language.
Co-authored-by: Cristian Adam <cristian.adam@gmail.com>
