2014-06-30 10:18 GMT+02:00 Stephen Kelly <steve...@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
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
