[CMake] Resolving static lib dependency at executable link time

[Leif Walsh]

I see. I would not try to express this complexity to cmake. Is there a way you can separate the alternate functionality out of C so that it doesn't cause the dependency graph to fragment this way? Usually circular dependencies mean you need to refactor something anyway. If you can make the dep graph more like this it could work:

EX1: D C B C B X1
EX2: D C B C B X2

(Where C1 was split into C and X1, and C2 was split into C and X2)

Sent from my iPhone

On Feb 25, 2013, at 8:38, Pierre Mallard <mallard.pierre at gmail.com> wrote:

> Hi everyone,
> 
> Reading answer from leif and andreas, leads me to advance a bit. 
> 
> To my opinion writing target_link_libraries(exe1 libB libC) would certainly works (but I m not able to test it at the moment).
> 
> But my problem should be explain the more tricky way :
> libB depends on libC function implementation but is a dependency of libD :
> 
> I got Exe depends upon libD which use libB which use libC. libC uses function defined in libB.
> 
> If I try Leif and Andreas idea : TARGET_LINK_LIBRARIES(Exe1 libD libC1)
> This line leads to output this gcc link line (schematically) :
> 
> gcc -o exe1 libD libC1 libB <==== Dependency of libD appears after all other "executable direct" dependencies
> 
> This does not work since libB depends on libC. The right gcc line would be :
> 
> gcc -o exe1 libD libC1 libB libC1 libB <==== I know this repetition of libB libC1 looks a bit stupid but it does not work else ...
> 
> These last line of gcc is what is done when setting all dependency. (TARGET_LINK_LIBRARIES(libB libC1) and TARGET_LINK_LIBRARIES(libC1 libB) but again the whole solution would require to build twice libB (and therefore libD and etc etc) to build with two different flavor of libC (libC1 and libC2).
> 
> Thks for your help ...
> Pierre
> 
> 
> 
> 
> 
> On Mon, Feb 25, 2013 at 2:14 PM, Andreas Stahl <andreas.stahl at tu-dresden.de> wrote:
>> Hello Pierre,
>> 
>> my knowledge concerning the linking process is rather limited, but wouldn't that mean you don't need to inter-link the libraries at all, when the symbols are resolved at link-time with the executable?
>> add_executable(ex1 libB libC1 libC2) should suffice then.
>> 
>> Best regards,
>> Andreas
>> 
>> 
>> Am 25.02.2013 um 13:47 schrieb Pierre Mallard:
>> 
>> > Well it is indeed possible and it works... Note that static libraries 's object files are built with unresolved symbols. Final resolution is performed when building executable
>> > Therefore libB can compile without libC and conversely ...
>> > Anyone else ?
>> >
>> >
>> >
>> > On Mon, Feb 25, 2013 at 12:23 PM, Ansis Māliņš <ansis.malins at gmail.com> wrote:
>> > >libB depends on libC and libC depends on libB.
>> > How is that even possible? You compile B and it fails because there's no C yet. You compile C and it fails because there's no B yet.
>> >
>> > --
>> >
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>> >
>> > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://www.cmake.org/mailman/listinfo/cmake
>> 
>> 
>> --
>> 
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>> 
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
> 
> --
> 
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130225/150566fe/attachment.htm>