[CMake] Modern cmake advise for transitive library dependencies

[Mario Emmenlauer]

Dear Craig, Alan,

thanks so much for this hint! I did not write the initial XConfig.cmake
myself and so it slipped my attention. Now things are perfectly clear,
I'll extend the XConfig.cmake.in and add the configuration steps there.

All the best,

     Mario



On 18.12.18 21:54, Craig Scott wrote:
> 
> 
> On Wed, Dec 19, 2018 at 5:36 AM Alan W. Irwin <Alan.W.Irwin1234 at gmail.com 
> <mailto:Alan.W.Irwin1234 at gmail.com>> wrote:
> 
>     On 2018-12-17 21:35+0100 Mario Emmenlauer wrote:
> 
>      >
>      > Dear cmake team and user community,
>      >
>      > I'd kindly like to ask for advice on how to handle transitive
>      > dependencies cleanly with "modern" cmake. I'm often plagued by this
>      > problem: I have a library X that optionally depends on library A.
>      > When I build library Y that depends on X, how do I (cleanly) handle
>      > the optional dependency A?
>      > Assume "A" would be "Qt5Core". I can link X publicly against Qt5::Core.
>      > But when I import X into Y, then Y will complain about unknown target
>      > Qt5::Core, unless I do find_package(Qt5 COMPONENTS Core) in Y. But since
>      > Qt is optional in X, I would need to track somehow if Qt was enabled
>      > before.
>      >
>      > But what good is the public transitive dependency when I manually need
>      > to track it, to find the libraries again? Am I missing something?
>      > Can the dependency be automatically resolved, or can I query some
>      > variable if X was linking A?
>      >
>      > How to do this cleanly?
> 
>     Hi Mario:
> 
>     One way to cleanly automate this is to configure the XConfig.cmake
>     file (depending on whether X is linked with Qt5 or not) to optionally
>     execute
> 
>     find_package(Qt5 ...)
> 
>     As a result, when the logic in XConfig.cmake is executed as a result of
> 
>     find_package(X ...)
> 
>     from Y, Qt5 should be found automatically when needed.
> 
> 
> 
> Your XConfig.cmake is responsible for also ensuring all targets it depends on 
> are defined. This shouldn't be left up to consumers of X. The way this is 
> normally done is pretty much as Alan suggests (it's also the way I handle cases 
> analogous to yours in our projects at work). There's even a find_dependency() 
> <https://cmake.org/cmake/help/latest/module/CMakeFindDependencyMacro.html> 
> command intended for precisely this situation to make it a little easier, 
> although I generally advise against using it for packages that support 
> components due to the way a particular optimisation in its implementation 
> affects later find_dependency() calls for the same package.
> -- 
> Craig Scott
> Melbourne, Australia
> https://crascit.com
> 
> New book released: Professional CMake: A Practical Guide 
> <https://crascit.com/professional-cmake/>



Viele Gruesse,

     Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/