[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