D7217: Separate private macro into KDevPlatformMacrosPrivate
Friedrich W. H. Kossebau
noreply at phabricator.kde.org
Wed Aug 9 14:42:39 UTC 2017
kossebau added inline comments.
INLINE COMMENTS
> KDevPlatformMacrosPrivate.cmake:32-39
> + target_include_directories(${target}
> + INTERFACE "$<INSTALL_INTERFACE:${KDE_INSTALL_INCLUDEDIR}/kdevplatform>"
> + "$<BUILD_INTERFACE:${KDevPlatform_SOURCE_DIR}>" "$<BUILD_INTERFACE:${KDevPlatform_BINARY_DIR}>"
> + "$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}>" # useful for the "something.export.h" includes
> + )
> + #some plugins install interfaces such as execute/iexecuteplugin.h
> + target_include_directories(${target} INTERFACE
Hm, on another look I am still wondering what the advantage of doing the $<BUILD_INTERFACE> variant is over just setting those include dirs globally.
It adds the very same non-lib-specific dirs to any lib.
And the ${KDevPlatform_*_DIR}/plugins ones even is rather a hack, as none of the libs these include dirs get set for actually provide those headers. That rule just makes sure that anyone using any of these libs also sees the additional headers provided by any plugins. While actually those wanting those additional headers from plugins should get a separate interface-only library target and link properly against it, no?
REPOSITORY
R32 KDevelop
REVISION DETAIL
https://phabricator.kde.org/D7217
To: kossebau, #kdevelop, apol
Cc: kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20170809/3ce6a557/attachment.html>
More information about the KDevelop-devel
mailing list