David Faure wrote: >> 3. We have situation >> >> a) framework A (public header use QObject and QWidget) >> -> LINK_PUBLIC only to Qt5::Widgets? or both Qt5::Core and Qt5::Widgets? > > I don't know if deps become part of it. I guess not, but I'm no expert. > Stephen? Alex?
I say target_link_libraries(A LINK_PUBLIC Qt5::Widgets) If B uses A, then it will do something like target_link_libraries(B LINK_PUBLIC A) that is, no need to list all public dependencies there, or for dependencies of B when using that etc. Qt5::Core is a public dependency of Qt5::Widgets (as is Qt5::Gui), so there's no need to try to be exhaustive with dependencies which cmake will add anyway. You only need to add 'leaf modules'. >> b) framework B (public header use QObject and QWidget and classes from >> frameworkA) >> -> LINK_PUBLIC same as in framework A plus KF5::FrameworkA? or only to >> KF5::FrameworkA because Qt5::Core and Qt5::Widgets are linked in >> frameworkA? Yes. I'm sure over time (and the further you get 'away' from Qt5::Core), people won't be listing it anyway. >> in short LINK_PUBLIC libraries are propagated and LINK_PRIVATE are not? >> :) Yes, exactly. If B uses Qt5::Sql internally, you would use: target_link_libraries(B LINK_PUBLIC A) target_link_libraries(B LINK_PRIVATE Qt5::Sql) or just target_link_libraries(B LINK_PUBLIC A LINK_PRIVATE Qt5::Sql) Thanks, Steve. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel