On 07/17/2015 01:43 PM, Tamás Kenéz wrote:
> 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
Okay, and of course that needs to include imported static libraries.
> Anyway, I understand
> 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 libr
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, to
I submitted a patch to update `CMakeExpandImportedTargets` with
`INTERFACE_LINK_LIBRARIES`.
Shortly after I read the discussion at http://www.cmake
.org/Bug/view.php?id=15299 which suggested `CMakeExpandImportedTargets` is
deprecated and one should use `BundleUtilities` instead.
Well, it seems tha
I've just read the discussion at
http://www.cmake.org/Bug/view.php?id=15299 about
the deprecation of CMakeExpandImportedTargets. I guess it means no fixes to
it.
I'm checking BundleUtilities as suggested there.
Tamas
On Wed, Jul 15, 2015 at 5:56 PM, Tamás Kenéz wrote:
> The CMakeExpandedImport
The CMakeExpandedImportedTargets module used only the deprecated
IMPORTED_LINK_INTERFACE_LIBRARIES property to resolve transitive
dependencies.
Since the current `install(EXPORT ...)` command generates target files that
populate INTERFACE_LINK_LIBRARIES instead, the expand module was not
working co
