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