libmm-qt/libnm-qt as KF5

[Lamarque Souza]

How are they are going to change? The "etc" here is important too. Remember
that NMQt follows NetworkManager's release numbers, the same is true for
MMQt and ModemManager. That is for simplify things for those who are used
to NetworkManager's release number, I prefer to keep that. Is there any
document explaining what is needed for a library to be part of KF5? I
prefer to know all the implications beforehand.

Keeping the dependencies for NMQt/MMQt to the minimum is important to make
them more available to other users. I know Plasma NM is the main user of
NMQt/MMQt. However we moved them to separated libraries to make them
usefull for non-KDE users as well. Adding ECM's kde-modules as dependencies
seems to break that goal. If it was not to make NMQt/MMQt usefull for
non-KDE users it would be simpler to merge them into Plasma NM again (like
they are in Plasma NM 0.9.0.x). That would remove the burden of keeping
binary compatibility from us.

Lamarque V. Souza

KDE's Network Management maintainer

http://planetkde.org/pt-br


On Mon, Apr 7, 2014 at 9:46 AM, Jan Grulich <jgrulich at redhat.com> wrote:

> Do you agree also with making libmm-qt/libnm-qt as KDE Frameworks? That
> means
> probably change versions, releasing etc.
>
> Jan
>
> On Monday 07 of April 2014 09:38 Lamarque Souza wrote:
> > Hi all,
> >
> > 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
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140407/70822aba/attachment-0001.html>