[cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty
Brad King
brad.king at kitware.com
Fri Jul 17 11:41:19 EDT 2015
On 07/16/2015 11:29 AM, Tamás Kenéz wrote:
> Well, it seems that `BundleUtilities` can't expand a single static imported
> library target to the list of all dependent libraries (that's what I need)
> so I think `CMakeExpandImportedTargets` is still benefitial and could be
> benefitial to others, too.
The BundleUtilities suggestion in the issue tracker page you linked
was specific to the CPack use case discussed there.
> My patch enables `CMakeExpandImportedTargets` to use the
> `INTERFACE_LINK_LIBRARIES` property and also resolves the $<CONFIG>,
> $<NOT> and $<0|1:> generator expressions.
This module should not be further maintained and should instead be
deprecated:
* Its original use case was to expand imported targets for calling
try_compile and try_run. Both now support imported targets
natively in their LINK_LIBRARIES options so it is no longer
needed (or used by CMake's own modules) for this purpose.
* It is not possible to implement with generator expressions in
general (see below).
> I found no elegant way to resolve all generator expressions
> (`file(GENERATE ...)` can't be used since it does not output the
> resolved content instantly).
Generator expressions by definition cannot be evaluated until generate
time because their evaluation can access information that is not
available until then. Even for imported targets with a given
CONFIGURATION value we may not have all the information needed to
expand INTERFACE_LINK_LIBRARIES. For example, that property may
contain expressions like $<TARGET_PROPERTY:prop> that refer to the
target for which the link line is currently generating.
What is your actual use case for expanding this info during the
configuration process?
-Brad
More information about the cmake-developers
mailing list