[cmake-developers] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty

Tamás Kenéz tamas.kenez at gmail.com
Fri Jul 17 13:43:38 EDT 2015


> What is your actual use case for expanding this info during the configuration
process?

We feed our static lib and the list of its dependencies to the `libtool` to
create an amalgamated, standalone static library.
This is an iOS-specific issue: we need this because iOS doesn't support
shared libraries and we want to provide our users a single static lib
instead of 20-30.

Anyway, I understand if `CMakeExpandImportedTargets' doesn't fit the
current concepts. We will then use a local modified copy of it or try to
solve the issue by `install(CODE ..)` to postpone the amalgamation to
install time where the generator expressions can be resolved.

Thanks,
Tamas

(sorry for not replying-to-all in previous email)


On Fri, Jul 17, 2015 at 5:41 PM, Brad King <brad.king at kitware.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150717/6c37394a/attachment.html>


More information about the cmake-developers mailing list