<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 19, 2018 at 5:36 AM Alan W. Irwin <<a href="mailto:Alan.W.Irwin1234@gmail.com">Alan.W.Irwin1234@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 2018-12-17 21:35+0100 Mario Emmenlauer wrote:<br>
<br>
><br>
> Dear cmake team and user community,<br>
><br>
> I'd kindly like to ask for advice on how to handle transitive<br>
> dependencies cleanly with "modern" cmake. I'm often plagued by this<br>
> problem: I have a library X that optionally depends on library A.<br>
> When I build library Y that depends on X, how do I (cleanly) handle<br>
> the optional dependency A?<br>
> Assume "A" would be "Qt5Core". I can link X publicly against Qt5::Core.<br>
> But when I import X into Y, then Y will complain about unknown target<br>
> Qt5::Core, unless I do find_package(Qt5 COMPONENTS Core) in Y. But since<br>
> Qt is optional in X, I would need to track somehow if Qt was enabled<br>
> before.<br>
><br>
> But what good is the public transitive dependency when I manually need<br>
> to track it, to find the libraries again? Am I missing something?<br>
> Can the dependency be automatically resolved, or can I query some<br>
> variable if X was linking A?<br>
><br>
> How to do this cleanly?<br>
<br>
Hi Mario:<br>
<br>
One way to cleanly automate this is to configure the XConfig.cmake<br>
file (depending on whether X is linked with Qt5 or not) to optionally<br>
execute<br>
<br>
find_package(Qt5 ...)<br>
<br>
As a result, when the logic in XConfig.cmake is executed as a result of<br>
<br>
find_package(X ...)<br>
<br>
from Y, Qt5 should be found automatically when needed.<br></blockquote><div><br></div><div><br></div><div>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 <a href="https://cmake.org/cmake/help/latest/module/CMakeFindDependencyMacro.html">find_dependency()</a> 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.</div><div> </div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">Craig Scott<br><div>Melbourne, Australia</div><div><a href="https://crascit.com" target="_blank">https://crascit.com</a><br></div><div><br></div><div>New book released: <a href="https://crascit.com/professional-cmake/" target="_blank">Professional CMake: A Practical Guide</a><br></div></div></div></div></div></div></div></div>