[cmake-developers] Optional dependencies in target INTERFACE
Philipp Moeller
bootsarehax at gmail.com
Mon Jun 30 10:09:59 EDT 2014
Stephen Kelly <steveire at gmail.com> writes:
> 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.
I use an approach similar to Daniel in my projects and never encode
optional dependencies. Each component or optional third party library
always comes with a define to notify other headers that it is
available. Maybe as a convenience another intermediate interface or
alias target could be added such as Boost::library_use_other_library.
Some Boost libraries also provide anti-feature macros and we could
enable them by default and disable them through the optional dependency,
so you always have to explicitly enable a dependency. Although I don't
see how this can be expressed easily through targets.
More information about the cmake-developers
mailing list