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

Reply via email to