Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists

[Jeremy Whiting]

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 <agateau at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel