[cmake-developers] Optional dependencies in target INTERFACE

[Daniel Pfeifer]

2014-06-30 10:18 GMT+02:00 Stephen Kelly <steveire at gmail.com>:

>
> Hello,
>
> QtSQL provides abstracted access to database data. It does not depend on
> QtGui or QtWidgets.
>
> It also provides the header-only qsqlrelationaldelegate.h. The contents of
> that header depend on QtWidgets, and are wrapped in an ifdef
> QT_WIDGETS_LIB.
> That means that the QSqlRelationalDelegate class is only available if that
> macro is defined, which is an effect of linking to Qt5Widgets anyway. This
> seems to be a good and well-working way to have an optional INTERFACE
> dependency.
>
> Unfortunately most projects do not have something similar to QT_WIDGETS_LIB
> macros.
>
> If a target is only a dependency if the depender uses a particular header,
> then should that target appear in the INTERFACE_LINK_LIBRARIES? If using
> QtGui but not using #include <qopengl> you do not depend on the GL
> libraries. If you add that include, you do depend on the GL libraries. Do
> the GL libraries belong in the INTERFACE_LINK_LIBRARIES of QtGui? That is
> the subject of
>
>  https://bugreports.qt-project.org/browse/QTBUG-39859
>
> In the case of modularized-Boost header-only libraries with INTERFACE
> targets, what criteria should be used to determine whether to put a
> dependency in the INTERFACE_LINK_LIBRARIES and make component packages? The
> actual dependencies required are determined by what the user #includes, not
> by what headers are #included by 'my' headers.
>

... or what the user uses *in addition*.

When my project depends on Boost.UUID but not on Boost.Serialization, then
I certainly don't need the optional serialization support of UUIDs.
If I want to use serialization, then Boost.Serialization has to be a direct
dependency of my project as I need to #include some of its headers directly.

I conclude that the optional dependency from Boost.UUID to
Boost.Serialization does not have to be represented at all.
Does that make sense?

-- Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140630/11174bf0/attachment-0002.html>