transitive interface dependency problem

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

transitive interface dependency problem

Starka Tomáš
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 | Threaded
Open this post in threaded view
|

Re: transitive interface dependency problem

CMake mailing list
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áš <[hidden email]> 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