On Thursday 26 September 2013, Aurélien Gâteau wrote:
> On Wednesday 25 September 2013 18:08:31 you wrote:
> [snip]
>
> > Do we know why do we need the KF5:: namespacing?
>
> I guess it is to avoid confusion: some frameworks are prefixed with 'k' but
> others are not (frameworkintegration, itemmo
On Thursday 26 September 2013 16:38:31 Martin Gräßlin wrote:
> On Thursday 26 September 2013 03:10:08 David Edmundson wrote:
> > Is there anything preventing us from using the ALIAS target right now?
>
> yes it got discussed a short time ago[1] and the result of the discussion
> was "no"
Yes, ple
On Thursday 26 September 2013 03:10:08 David Edmundson wrote:
> Is there anything preventing us from using the ALIAS target right now?
yes it got discussed a short time ago[1] and the result of the discussion was
"no"
Cheers
Martin
[1] See thread with message id starting on Aug,
20th.
signatu
On Thu, Sep 26, 2013 at 5:10 AM, David Edmundson wrote:
> Is there anything preventing us from using the ALIAS target right now?
>
> It's in the git version. The build guide say to get cmake from git.
> kdesrc-build gets it from git, and build.kde.org uses git latest.
>
> I just set KWindowSystem
On Thursday 26 September 2013 03:10:08 David Edmundson wrote:
> Is there anything preventing us from using the ALIAS target right now?
>
> It's in the git version. The build guide say to get cmake from git.
> kdesrc-build gets it from git, and build.kde.org uses git latest.
+1 for me.
That would
Is there anything preventing us from using the ALIAS target right now?
It's in the git version. The build guide say to get cmake from git.
kdesrc-build gets it from git, and build.kde.org uses git latest.
I just set KWindowSystem to have an alias and tried building
knotifications. It worked beaut
On Wednesday 25 September 2013 13:52:01 Nicolás Alvarez wrote:
> 2013/9/25 Aurélien Gâteau :
> > 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
On Wednesday 25 September 2013 18:08:31 you wrote:
[snip]
> Do we know why do we need the KF5:: namespacing?
I guess it is to avoid confusion: some frameworks are prefixed with 'k' but
others are not (frameworkintegration, itemmodels, itemviews, solid, sonnet,
threadweaver, xmlgui).
It's true w
On Wednesday 25 September 2013 19:13:00 Alexander Neundorf wrote:
> On Wednesday 25 September 2013, Aurélien Gâteau wrote:
> ...
>
> > 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 u
On Wednesday, September 25, 2013 17:42:35 Aurélien Gâteau wrote:
> 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":
>
>
Jeremy Whiting wrote:
> Aurélien,
>
> Thanks for the detailed explanation. Now the questions become:
>
> a) when will that cmake feature be in a released version of cmake?
Impossible to know. I expected it would be released weeks ago. I guess it
will be a few weeks more.
> b) what should we
On Wednesday 25 September 2013, Aurélien Gâteau wrote:
...
> 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 tie
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 _
On Wed, Sep 25, 2013 at 6:52 PM, Nicolás Alvarez
wrote:
> 2013/9/25 Aurélien Gâteau :
> > 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 i
2013/9/25 Aurélien Gâteau :
> 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
On Wed, Sep 25, 2013 at 5:42 PM, Aurélien Gâteau 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 d
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 o
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 Pl
18 matches
Mail list logo
