<div dir="ltr">On Wed, Sep 25, 2013 at 5:42 PM, Aurélien Gâteau <span dir="ltr"><<a href="mailto:agateau@kde.org" target="_blank">agateau@kde.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

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