Aurélien, Thanks for the detailed explanation. Now the questions become:
a) when will that cmake feature be in a released version of cmake? b) what should we do to get frameworks ready if not making them build by themself and part of kdelibs both? I guess I can go rename my private headers to _p.h and such, but otherwise I'm waiting for a cmake release to continue? thanks, Jeremy On Wed, Sep 25, 2013 at 9:42 AM, Aurélien Gâteau <agat...@kde.org> wrote: > On Wednesday 25 September 2013 12:04:11 Aurélien Gâteau wrote: >> On Wednesday 25 September 2013 11:22:57 Sebastian Kügler wrote: >> > CMake-gods, can you confirm the below? (It's inconsistent with my >> > understanding, and how we've done it in the past months, I'd like to have >> > a >> > specialist opinion before going around and changing every single >> > CMakeLists.txt in Plasma.) >> >> My cmake-fu is far from god-level, but my experience is that for frameworks >> to build standalone, they must link to other frameworks using >> ${foo_LIBRARIES} rather than KF5::Foo. >> >> I take it this is the reason kdelibs/CMakeLists.txt defines many >> ${foo_LIBRARIES} variables. > > Replying to myself: this topic was discussed on IRC with Stephen Kelly, the > result is the following: > > # Short version > > 1. To use the "Foo" framework within another framework whose code is in > kdelibs, use "Foo": > > target_link_libraries(bar Foo...) > > 2. To use the "Foo" framework outside of kdelibs, use "KF5::Foo": > > target_link_libraries(external_project KF5::Foo) > > 3. Standalone builds of tier2 and tier3 are not possible for now. > > # Long version > > When building all of kdelibs, a framework can refer to other frameworks by > their target name since they are all part of the "kdelibs" cmake project. For > example, KCompletion can link to KConfigCore like this: > > target_link_libraries(KCompletion LINK_PRIVATE KConfigCore) > > When building KCompletion standalone, it is no longer part of the "kdelibs" > cmake project and cannot find KConfigCore, one would thus need to change the > target_link_libraries call to this: > > target_link_libraries(KCompletion LINK_PRIVATE KF5::KConfigCore) > > But that would break the all-in-one build of kdelibs, since in this context > KF5::KConfigCore is not defined. > > The solution to this is ALIAS targets, as explained by Stephen here: > http://thread.gmane.org/gmane.comp.kde.devel.core/80233/focus=80247 > > With ALIAS targets, one would define an alias like this when building kdelibs: > > add_library(KF5::KCoreAddons ALIAS KCoreAddons) > > This would make it possible for the kdelibs all-in-one build to find > KCoreAddons. > > Unfortunately, ALIAS is a new feature of the add_library command, which is > only available in cmake git for now and will be in 2.8.12. Therefore we cannot > use this solution right now. This means we can't have standalone builds of > tier2 and tier3 frameworks. tier1 frameworks are OK since by definition they > do not depend on other frameworks. > > The alternative syntax: ${KConfigCore_LIBRARIES} would work in both cases, but > it is more error prone: any typo in the variable name causes the variable to > be expanded to an empty string, making it more difficult to debug, whereas > using target names provide more explicit error messages. > > Aurélien > _______________________________________________ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel