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 <mgraess...@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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
