If `interfaceDep` is an actual interface target, consuming libraries of libA inside the project ( example ) should resolve it as an interface target and not drop it on the lnik line.
If you have a small self contained example that would help track down this issue. On Thu, Feb 21, 2019 at 5:49 AM Starka Tomáš <sta...@fit.vutbr.cz> wrote: > > Hi all, > following my previous post 'link only with targets feature' I have > found yet another unpleasant consequence of not being able to tell > cmake that it is the target name in the parameters of > target_link_libraries (without the use of :: notation, that is > optional and inconsistent). When I have library A which have an > interface dependency interfaceDep and when using the export sets to > automaticaly generate the configs while simultaneously internaly > building an example app that is using lib A. I have encountered the > following problem: > In the cmake of lib A I do NOT search for the interfaceDep since > there is no reason to, because the lib A compiles and links without > it. But to relate that dependency to autogenerated config I need to > state target_link_libraries(A INTERFACE interfaceDep), and then, for > downstreamers, I need to handle the finding of it by hand in the > config before the *Targets.cmake gets included (that's kind of ok and > could be automated by cmake if we had consistent target naming > syntax). Back to the build tree of the project for lib A. In the later > subdirectories where I build an example app the > target_link_libraries(example A) makes it wants interfaceDep.lib > (which is non-existent since its only interface lib) eventhough there > is correct interfaceDep target found prior to that in the app cmake. > The thing is that the interfaceDep is resolved not in the application > cmake but in the lib A cmake where there is no target of that name and > the target_link_libraries doesn't know that it is supposed to be a > target. I hope I didn't lost you yet. > I have come with two solutions. One is to not use INTERFACE > dependencies ever and injecting them by hand in the config scripts for > downstreamers - which seems more dirty and confusing and then in the > same buildtree doing the same for all the apps/libs that uses lib A. > The other solution is to create a dummy target - > add_library(interfaceDep INTERFACE IMPORTED) in the lib A cmake just > before you call target_link_libraries(A INTERFACE interfaceDep), which > is less dirty but dirty nontheless. > Is there any other idiomatic approach? And NOTE that "use > interfaceDep::interfaceDep" named target is not possible since it > could be target created by 3rd party and you can't alias an IMPORTED > target ;) (e.g. glm). It would realy help if there would be a 'link > only with targets feature' in the cmake with all the consequences. > If you see it fit, you can also forward this to the developer only > mailing-list. But I've started a new thread since it opens (and > possibly resolves) a new isssue. > > Hope posing these points will help > forry > > -- > > 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: > https://cmake.org/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: https://cmake.org/mailman/listinfo/cmake
