libmm-qt/libnm-qt as KF5

[Lamarque Souza]

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/8ec6cbdf/attachment.html>