[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-frameworks-devel
Subject: Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
From: Aleix Pol <aleixpol () kde ! org>
Date: 2013-09-25 16:08:31
Message-ID: CACcA1RrAirZhYdRykNavW-QDFB+zz4Hfby9RFWogOCdeNt17SQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Sep 25, 2013 at 5:42 PM, Aurélien Gâteau <agateau@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
>
Do we know why do we need the KF5:: namespacing?
Aleix
[Attachment #5 (text/html)]
<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>
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic