libmm-qt/libnm-qt as KF5

[Mario Fux]

Am Montag, 07. April 2014, 14.38:14 schrieb Lamarque Souza:
> Hi all,

Morning Lamarque

> I have cloned ECM git repo and looked at it. I agree that it is small and
> it has useful features for NMQt/MMQt. I like the fact that it provides a
> FindNetworkManager.cmake. Ok, we can make ECM a hard dependency for
> NMQt/MMQt.
> 
> My only concern now is the kde-modules that Jan used in NMQt/MMQt's
> framework branches. Is it necessary to have KF5 installed to use those

Here still seems to be a misunderstanding about KDE Frameworks (KF5). The goal 
and idea was and is it to modularize kdelibs so that people can pick the 
frameworks (e.g. KConfig and Sonnet) they need for an app and don't need to 
use and install all of them. So for the case of our (KDE) apps a lot (or most) 
of them will depend on many or all of the Frameworks in KF5. But all other Qt 
apps and libs that want to use the KDE Frameworks can just pick the once they 
need.

Hope that clarifies KF5 a bit
Mario

> modules? I am asking it because I did not find where in ECM repo the
> macro _kde_add_platform_definitions is defined.
> 
> Lamarque V. Souza
> 
> KDE's Network Management maintainer
> 
> http://planetkde.org/pt-br
> 
> On Mon, Apr 7, 2014 at 5:31 AM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> > On Monday 07 April 2014 10:14:12 David Faure wrote:
> > > On Monday 07 April 2014 09:47:43 Jan Grulich wrote:
> > > > You are still talking about users, but I'm sure that 99% of them will
> > > > install it from distro repositories and because e-c-m is build
> > 
> > dependency,
> > 
> > > > they won't notice that. For remaining 1% of users you are talking
> > > > about will be e-c-m available from distro repositories as well, so
> > > > what's the problem? Now those libraries are compiled mostly because
> > > > of Plasma NM, which requires unreleased versions (i.e. for
> > > > frameworks version) and in this case they have already e-c- m
> > > > installed.
> > > > 
> > > > I don't want to have libnm-qt/libmm-qt as separated libraries, I
> > > > think that
> > > > a lot of distributions have them in their repositories, because they
> > 
> > are
> > 
> > > > as
> > > > dependency for Plasma NM. I would be really interested how many
> > > > distributions would have it without Plasma NM. It makes sense to me
> > > > be part
> > > > of KF5, don't be separated and be more visible and available for
> > > > other developers and users and probably less confusing for
> > > > packagers.
> > > 
> > > I agree. ECM is a very tiny dependency to have, and in return it solves
> > > a large number of issues for you (deployment, cmake config files,
> > > qmake
> > 
> > .pri
> > 
> > > file, dependency handling for users of your libs, forwarding headers,
> > > versioning, releasing, etc. etc.).
> > 
> > This is IMHO the important point. Just look at what ECM provides and you
> > will
> > realize that it's extremely useful and that even if those libraries will
> > not
> > end up in KF5, they will use ECM. How can I do such a bold statement?
> > Because
> > ECM solves real world problems you want to have solved in your library,
> > too.
> > The developers using your library will expect a proper Config.cmake file
> > and a
> > proper Version.cmake file and ECM solves that for you. I'm using ECM in
> > libraries not intended to ever be part of KF5 exactly for that and before
> > I added that dependency it was just not possible to reliable use the
> > library.
> > 
> > Of course you can also write that CMake Foo all by yourself but I have
> > the feeling that the knowledge to write proper CMake Foo is not wide
> > spread among
> > our developers. I personally prefer to use the CMake Foo written by
> > people who
> > know their stuff instead of doing my own.
> > 
> > Cheers
> > Martin