D7217: Separate private macro into KDevPlatformMacrosPrivate

[Kevin Funk]

kfunk added inline comments.

INLINE COMMENTS

> KDevPlatformMacrosPrivate.cmake:1
> +#
> +# KDevelop Platform Private Macros

Usually these files are called FooInternal.cmake [1] . Please use this pattern

  % dpkg -S Private | grep cmake
  % dpkg -S Internal | grep cmake                                                                                                                                        
  kdelibs5-dev: /usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake
  libphonon-dev: /usr/share/phonon/buildsystem/FindPhononInternal.cmake
  cmake-data: /usr/share/cmake-3.7/Modules/Compiler/IBMCPP-C-DetermineVersionInternal.cmake
  cmake-data: /usr/share/cmake-3.7/Modules/Internal/FeatureTesting.cmake
  cmake-data: /usr/share/cmake-3.7/Modules/Compiler/Clang-DetermineCompilerInternal.cmake
  cmake-data: /usr/share/cmake-3.7/Modules/Compiler/IBMCPP-CXX-DetermineVersionInternal.cmake
  libphonon4qt5-dev: /usr/share/phonon4qt5/buildsystem/FindPhononInternal.cmake
  cmake-data: /usr/share/cmake-3.7/Modules/Internal

> kossebau wrote in KDevPlatformMacrosPrivate.cmake:32-39
> 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?

> 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.

Still feels cleaner to me. You might have a small test executable which does not link to any of these libs => then without this this test target might see include paths it is not interested in.

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D7217

To: kossebau, #kdevelop, apol
Cc: kfunk, kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20170809/576ddeb7/attachment-0001.html>