[cmake-developers] When should a library be in LINK_INTERFACE_LIBRARIES?

[Brad King]

On 3/23/2012 9:15 AM, Stephen Kelly wrote:
> There is a debate over the QtQml module at the moment. It has in one of its
> interface classes (QQmlEngine) a method QNetworkAccessManager
> *networkAccessManager() const, and the QNetworkAccessManager class is
> forward declared.
>
> https://qt.gitorious.org/qt/qtdeclarative/blobs/master/src/qml/qml/qqmlengine.h
>
> The QNetworkAccessManager class is in the QtNetwork module.
>
> One can use the QQmlEngine class without linking to QtNetwork. It would only
> be necessary to link to QtNetwork if the networkAccessManager() method is
> called. Otherwise, it is overlinking.
>
> So I'm looking for other opinions. Should the LINK_INTERFACE_LIBRARIES
> contain all dependencies that could possibly be needed, or just the minimum
> (if you don't use these libraries, you code won't work at all)?

The general rule is that if an application can get a direct link
dependency on library A by including headers documented for library
B then A should be in B's link interface.  This is common when A's
headers define a base class and B's headers include them and derive
from it.  Using B's interface might directly call symbols from A but
the application should not have to know that, so A goes in B's link
interface.

If an application calls the networkAccessManager() method it still
will not get any link-time dependencies on QtNetwork because the
return type is a pointer to an incomplete type.  Only by including
a header that defines QNetworkAccessManager and calling methods on
that can a link dependency be introduced.  Once the application has
included that header then it should be responsible for linking to
the corresponding library.

Therefore QtNetwork should not be in the link interface of QtQml,
at least not for this reason.

-Brad