Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
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 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.
I said it before, this alternative syntax has the advantage that it has
been working in cmake forever, and all developers using cmake know this
syntax.
Agreed. I personally believe we should ensure frameworks in tierX are really
building standalone as soon as possible. After all, this is the whole point of
splitting kdelibs. As such I was personally in favor of using variables for
now, and do a massive fix once we can depend on cmake 2.8.12, but Kevin and
David prefer waiting for 2.8.12 to be available. I respect their decision.
Calling being able to make typos in variable names a disadvantage
seems weird to me. This applies to all variables you'll ever use in cmake,
everywhere.
True, and it is one of my most hated CMake feature.
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
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 we wouldn't have this problem if we were not using namespaces though... Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
On Wednesday 25 September 2013 13:52:01 Nicolás Alvarez wrote:
2013/9/25 Aurélien Gâteau agat...@kde.org:
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.
Have you tried using cmake --warn-uninitialized?
I didn't know --warn-uninitialized. It's quite handy, but as Aleix said it's
way too verbose right now with kdelibs, plus it's just a warning, whereas a
missing will stop the build with an error.
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
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 indeed be the simplest solution. It is consistent with the build docs and is the fastest way to get us to fully standalone frameworks. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
On Thu, Sep 26, 2013 at 5:10 AM, David Edmundson da...@davidedmundson.co.uk 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 to have an alias and tried building knotifications. It worked beautifully, http://paste.kde.org/pde423295 Both full kdelibs built as well as knotifiications standalone, which previously failed. It even helped me find a missing find_package(!) that would have otherwise gone unnoticed till we split, which would have a been a real nuisance. Doing this will allow us to make sure each tierN module actually builds standalone, and saves us having to set all the lib names twice if we are porting to KF5::LibName eventually. Downside is people using old cmake will need to sort themselves out and upgrade. (including project-neon-5) David ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Well, it's a bit of a burden to depend on git versions of cmake, that's why it's not being used so far. Personally, my plan was to do all the splitting now and then think about building things separately once everything is split. I see that it's annoying for you to work like that, so I don't have a problem with using newer cmake versions and get rid of this problem once and for all. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
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 kv0jqj$qvd$1...@ger.gmane.org starting on Aug, 20th. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
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, please people dig your archives... We've been through that already. Bottom line: use target names, no modular build for tier n + 1 for now, will get fixed once cmake 2.8.12 is out. Thanks. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
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, itemmodels, itemviews, solid, sonnet, threadweaver, xmlgui). It's true we wouldn't have this problem if we were not using namespaces though... The namespacing is there to give the reader a hint that this thing is not simply the basename of a library, but an (imported) target. If you would simply use e.g. solid, if the target has, for whatever reason, not been imported, cmake would consider it as the basename of a library and add -lsolid, and it may work or not. CMake will actually do the same with KF5::solid, but at least for the reader it should give a strong hint that this is not the basename of a library. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
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.
Aurélien
-- Forwarded Message --
Subject: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
Date: Wednesday, September 25, 2013, 10:36:46
From: Martin Gräßlin mgraess...@kde.org
To: plasma-de...@kde.org
Hi all,
just a short reminder. When adjusting a CMakeLists.txt to Qt5 to enable e.g.
a dataengine please use the new namespace syntax in target_link_libraries.
E.g:
target_link_libraries(plasma_engine_notifications
Qt5::DBus
KF5::KI18n
KF5::KIconThemes
KF5::KIOCore
KF5::KNotifications
KF5::plasma
KF5::KService
${KDE4_KNOTIFYCONFIG_LIBRARY}
)
and not
target_link_libraries(plasma_engine_notifications
Qt5::DBus
${Plasma_LIBRARIES}
${KI18n_LIBRARIES}
${KIconThemes_LIBRARIES}
${KNotifications_LIBRARIES}
${KService_LIBRARIES}
${KDE4_KIO_LIBS}
${KDE4_KNOTIFYCONFIG_LIBRARY}
)
I just spent the last half our fixing linker errors as ${KI18n_LIBRARIES}
didn't exist any more.
Thanks,
Martin
-
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
2013/9/25 Aurélien Gâteau agat...@kde.org:
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.
Have you tried using cmake --warn-uninitialized?
--
Nicolás
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
On Wed, Sep 25, 2013 at 6:52 PM, Nicolás Alvarez
nicolas.alva...@gmail.comwrote:
2013/9/25 Aurélien Gâteau agat...@kde.org:
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.
Have you tried using cmake --warn-uninitialized?
--
Nicolás
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
It's not really an alternative, it becomes far too verbose.
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
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 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.
I said it before, this alternative syntax has the advantage that it has been
working in cmake forever, and all developers using cmake know this syntax.
Calling being able to make typos in variable names a disadvantage seems weird
to me. This applies to all variables you'll ever use in cmake, everywhere.
Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
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 do to get frameworks ready if not making them build by themself and part of kdelibs both? Using variables would be an option. 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? What does naming headers have to do with the issue under discussion? Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
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: 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. Thanks for creating clarity. :) -- sebas, goes to rename a lot of variables in cmake files all over Plasma =) http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
