[CMake] Link order and interface multiplicity

[Robert Maynard]

No you would set the properties on ExeA and ExeB and that would effect the
target_link_library generation for the interface library I

I have written an example that drops the Foo libraries as they aren't
needed to show my example.

https://github.com/robertmaynard/Sandbox/blob/master/CMakeInterfaceChangesLibrary/CMakeLists.txt

On Wed, May 17, 2017 at 5:15 PM, Etan Kissling <kissling at oberon.ch> wrote:

> Not sure if I understand that correctly, but isn't that essential the same
> as creating a FooA and BarA that link to IA, and a FooB and BarB that link
> to IB, and linking ExeA to FooA and ExeB to FooB?
>
> Problem with this approach is that there are more than two implementations
> of I, and way more than two Exes ^_^
>
> Thanks for the input, though!
>
> Etan
>
> On 17 May 2017, at 18:49, Robert Maynard <robert.maynard at kitware.com>
> wrote:
>
> I have a feeling that you could do this with generator expressions. You
> would have the interface link line for I have a generator expression that
> switches between IA and IB. Than you would setup ExeA and ExeB to trigger
> this switch. Maybe using something like $<TARGET_PROPERTY:prop>?
>
> On Wed, May 17, 2017 at 8:28 AM, Etan Kissling <kissling at oberon.ch> wrote:
>
>> Hi, and thanks for the quick reaction :-)
>>
>> The approach with forward declaration looks interesting. However, I don't
>> think that it will resolve all the problems.
>>
>> One issue is that there are multiple apps, each using separate
>> implementations.
>> • ExeA uses the generic libraries Foo and Bar, as well as the **IA**
>> implementation of interface library I.
>> • ExeB uses the generic libraries Foo and Bar, as well as the **IB**
>> implementation of interface library I.
>>
>> On top of that, I'd like to be able to build Foo and Bar independently as
>> static libraries, without IA or IB being present.
>>
>> Is it possible to replace references to interface library I with
>> implementation IA, but only while ExeA is being compiled, and vice versa
>> for ExeB?
>> There are only static libraries involved, so the compilation of Foo / Bar
>> should be the same in both cases.
>>
>> Thanks
>>
>> Etan
>>
>>
>>
>> > On 16 May 2017, at 10:39, Patrick Boettcher <
>> patrick.boettcher at posteo.de> wrote:
>> >
>> > Hi,
>> >
>> > On Mon, 15 May 2017 12:30:10 +0000
>> > Etan Kissling <kissling at oberon.ch> wrote:
>> >> I have a project with a layer consisting of interface libraries:
>> >>      add_library(I INTERFACE)
>> >>
>> >> These interface libraries are then implemented several times, to fit
>> >> the different environments of applications: add_library(IA STATIC ...)
>> >>      target_link_libraries(IA PUBLIC I)
>> >>
>> >>      add_library(IB STATIC ...)
>> >>      target_link_libraries(IB PUBLIC I)
>> >>
>> >> There are also application independent libraries, that make use of
>> >> the interface libraries. add_library(Foo STATIC ...)
>> >>      target_link_libraries(Foo PUBLIC I)
>> >>
>> >>      add_library(Bar STATIC ...)
>> >>      target_link_libraries(Bar PUBLIC I)
>> >>
>> >> And finally, the application defines which implementation of the
>> >> interface library layer is being used.
>> >>
>> >>      add_executable(ExeA ...)
>> >>      target_link_libraries(ExeA Foo Bar IA)
>> >>
>> >>      add_executable(ExeB ...)
>> >>      target_link_libraries(ExeB Foo Bar IB)
>> >>
>> >>
>> >> Luckily, this is okay, as long as IA is listed after Foo and Bar in
>> >> the synthesized link command.
>> >>
>> >> However, certain implementations of I make use of the application
>> >> independent libraries again. On these environments, the link command
>> >> line becomes something like this:
>> >>
>> >> IA Foo Bar
>> >>
>> >> While it should be
>> >>
>> >> Foo Bar IA Foo Bar
>> >>
>> >> This make sense, because there is no explicit dependency being
>> >> described that Foo / Bar depend on IA while compiling ExeA. In the
>> >> simple case, we just get lucky, because it happens to be the default
>> >> that link command line has the same order as in the
>> >> target_link_libraries call.
>> >
>> > I wouldn't try my luck if I were you. Always be explicit, especially
>> > with dependencies, otherwise, at some point in time, cmake won't get it
>> > right when generating the order of link.
>> >
>> > What you could try is "forward" declaring a
>> > platform/app-dependent dependencies with interface libraries:
>> >
>> > In CMakeLists.txt
>> >
>> >  add_library(top-level-I INTERFACE)
>> >  target_link_libraries(top-level-I INTERFACE app-dependent-I)
>> >    # here we forward declare app-dependent-I
>> >
>> >  add_subdirectory(app) # app-dependent
>> >
>> >  add_executable(test2 test2.cpp)
>> >  target_link_libraries(test2 top-level-I) # will link with IA and IB
>> >
>> > In app/CMakeLists.txt
>> >
>> >  add_library(app-dependent-I INTERFACE)
>> >  target_link_libraries(app-dependent-I INTERFACE IA IB)
>> >    # here we "implement"
>> >
>> >  add_library(IA ...)
>> >  add_library(IB ...)
>> >
>> > app-dependent-I is a forward declared libraries - cmake will evaluate
>> > this at generation-time. This will get you the dependencies right.
>> >
>> > I hope I correctly understood your question.
>> >
>> > --
>> > Patrick.
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170517/09047cd0/attachment.html>