[CMake] Modern cmake advise for transitive library dependencies

[Alan W. Irwin]

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.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________