Hi, I understood that, I just do not know all the other things we need to do to make NMQt/MMQt part of KF5. And yes, I agree in making NMQt/MMQt part of KF5. The other doubt I still have is where _kde_add_platform_definitions is defined. By what I could figure out it is not in ECM, so something else is needed to parse the CMakeLists.txt file in current NMQt's framework branch.
As for my questioning about merging NMQt/MMQt into plasma-nm repo is because every time I argue that we should make them usable for non-KDE users arguments like this appears: "I would be really interested how many distributions would have it [NMQt] without Plasma NM.". Now I am wondering if I am the only one that still thinks NMQt/MMQt are useful for other software besides Plasma NM. Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br On Mon, Apr 7, 2014 at 10:11 AM, Mario Fux <kde...@unormal.org> wrote: > Am Montag, 07. April 2014, 14.38:14 schrieb Lamarque Souza: > > Hi all, > > Morning Lamarque > > > 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 > > Here still seems to be a misunderstanding about KDE Frameworks (KF5). The > goal > and idea was and is it to modularize kdelibs so that people can pick the > frameworks (e.g. KConfig and Sonnet) they need for an app and don't need to > use and install all of them. So for the case of our (KDE) apps a lot (or > most) > of them will depend on many or all of the Frameworks in KF5. But all other > Qt > apps and libs that want to use the KDE Frameworks can just pick the once > they > need. > > Hope that clarifies KF5 a bit > Mario > > > 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
