[CMake] Controlling the targets in an export set

[Adar Dembo]

Thanks, that did the trick (though I had to use LINK_PRIVATE instead of
PRIVATE; maybe I'm using an older version of cmake).

And yes, I need -fPIC code through and through. I've already taken care of
that.

And double yes, a few other targets needed to explicitly list foo's
transitive dependencies in their own target_link_libraries(). Wasn't too
hard to fix though.


On Thu, Jul 24, 2014 at 12:15 AM, Nils Gladitz <nilsgladitz at gmail.com>
wrote:

> On 07/24/2014 01:57 AM, Adar Dembo wrote:
>
>> I have a project that generates a shared library foo. As part of the
>> build, the bar1, bar2, and bar3 static archives are created, and
>> eventually, foo is linked against all of them. Thus, the project's sole
>> deliverable is libfoo.so; all the necessary symbols from the bar1..bar3
>> archives are found within libfoo.so.
>>
>> If I try to export foo using "install(TARGETS foo EXPORT foo ...) and
>> "install(EXPORT foo ...)", cmake complains that target foo requires
>> targets bar1, bar2, and bar3, which are not in the export set. I have to
>> add "install(TARGETS bar1 EXPORT foo ...)" for bar1..bar3 if I want this
>> to succeed. However, this also means that I'm exporting my static
>> archives, which as I wrote earlier aren't necessary.
>>
>> How can I exercise finer-grained control over foo's export set? How can
>> I build an export set containing foo but excluding bar1, bar2, and bar3?
>>
>
> You can link your static libraries to your shared library privately hence
> removing them from foo's interface:
>
>   target_link_libraries(foo PRIVATE bar1 bar2 bar3)
>
> You are probably already aware but just in case ...
>
> To portably link archives to shared libraries you need position
> independent code[1].
>
> Of the objects contained in your archives only those will get included
> which are required to resolve some reference when creating libfoo.so.
> Symbols that were contained in objects which were not required in the link
> will hence not be available.
>
> This might seemed to have worked within the project until now given that
> the archives were in your link interface.
>
> Nils
>
> [1] http://cmake.org/cmake/help/v3.0/prop_tgt/POSITION_
> INDEPENDENT_CODE.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20140724/e265d180/attachment.html>