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

[Aleix Pol]

On Wed, Sep 25, 2013 at 5:42 PM, 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
>

Do we know why do we need the KF5:: namespacing?

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130925/88884434/attachment.html>