[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cmake
Subject:    Re: [CMake] transitive interface dependency problem
From:       Robert Maynard via CMake <cmake () cmake ! org>
Date:       2019-02-27 14:03:17
Message-ID: CAFzjYVr5V7jQ-DHH7YwPN8OMmt83Ty+cwdjioWogHdPoy_1rkg () mail ! gmail ! com
[Download RAW message or body]

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áš <starka@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


[prev in list] [next in list] [prev in thread] [next in thread]