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 <kissl...@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.mayn...@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 <kissl...@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.boettc...@posteo.de> wrote: >> > >> > Hi, >> > >> > On Mon, 15 May 2017 12:30:10 +0000 >> > Etan Kissling <kissl...@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 >> > >
-- 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