[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