Quantcast

Link order and interface multiplicity

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Link order and interface multiplicity

Etan Kissling
Heya,

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'm working with gcc-arm-none-eabi cross compiler. Here's what I've tried:
• LINK_INTERFACE_MULTIPLICITY
        Does not seem to work. The generated command line is still the same even with higher numbers.
• set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,--start-group")
        Linking succeeds, but the program does not run properly on the target hardware. Only after connecting a debugger and resetting, it runs. Strange behaviour.
        When I link Foo / Bar explicitly with IA instead of --start-group, the command line becomes Foo Bar IA Foo Bar, and then everything works fine. But I cannot do this in general, because of ExeB ^^


=> Is there a way how I can define that Foo / Bar temporarily depend on IA while compiling ExeA, and temporarily depend on IB while compiling ExeB?
=> Is there a different approach on how to handle project structured like the one described above?

Thanks

Etan
--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Link order and interface multiplicity

Patrick Boettcher
Hi,

On Mon, 15 May 2017 12:30:10 +0000
Etan Kissling <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Link order and interface multiplicity

Etan Kissling
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 <[hidden email]> wrote:
>
> Hi,
>
> On Mon, 15 May 2017 12:30:10 +0000
> Etan Kissling <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Link order and interface multiplicity

Robert Maynard
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 <[hidden email]> 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 <[hidden email]> wrote:
>
> Hi,
>
> On Mon, 15 May 2017 12:30:10 +0000
> Etan Kissling <[hidden email]> 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


--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Link order and interface multiplicity

Etan Kissling
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>
> Hi,
>
> On Mon, 15 May 2017 12:30:10 +0000
> Etan Kissling <[hidden email]> 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


--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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.


On Wed, May 17, 2017 at 5:15 PM, Etan Kissling <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>
> Hi,
>
> On Mon, 15 May 2017 12:30:10 +0000
> Etan Kissling <[hidden email]> 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



--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Link order and interface multiplicity

Patrick Boettcher
In reply to this post by Etan Kissling
On Wed, 17 May 2017 21:15:39 +0000
Etan Kissling <[hidden email]> 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 ^_^
 
Could you create an example repository (on github for example) which
templates what you're trying to achieve?

From what I understood so far, I doubt that all of it can be
achieved in one cmake-build. Maybe you need to create a super-project
and work with export() and include().

regards,
--
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
Loading...