libmm-qt/libnm-qt as KF5

[Martin Gräßlin]

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140407/d01436fd/attachment.sig>