On Friday 19 July 2013, Stephen Kelly wrote: > Stephen Kelly wrote: > > 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'. > > To be more clear. I'm saying only what CMake requires. Public dependencies > (if correctly listed) can't be removed or changed without breaking binary > compatibility. > > For policy of what to do in KF5, don't ask me :). I prefer minimalism but > I'll let others figure out what to do there.
As everybody probably knows in the meantime, I prefer making things obvious and explicit. This may need somewhat more code, but makes it easier to understand and maintain. In this case: if C directly uses A and B, I would prefer to list both as dependencies for C, instead of relying on the fact that the author knows that A will be dragged in via B. What happens if you would hide the dependency from C to A ? Maybe B at some point does not use A anymore, then C will not build anymore because A is missing. Without listing A, a patch is needed to make C build again (although C was not changed): -target_link_libraries(C B) +target_link_libraries(C B A) Or if I refactor C and port it away from B (but still use A), if I simply remove B from the dependencies it will not build anymore, because A is missing. Without listing A, the patch would be -target_link_libraries(C B) +target_link_libraries(C A) which looks like "I replaced B by A". With listing A, the patch would be -target_link_libraries(C B A) +target_link_libraries(C A) which IMO clearly says "C doesn't use B anymore". Or somebody else reads the code (who does not know that B drags in A) and does not see A listed as dependency, he may think that C does not depend on A, or only accidentially depends on A. So, yes, I'm for clearly stating the public dependencies. Alex _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
