libmm-qt/libnm-qt as KF5

[Jan Grulich]

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