On Friday 01 November 2013, Mirko Boehm wrote: > On 11/01/2013 01:53 PM, Sune Vuorela wrote: > >> So far we chose the "have it in cmake/ecm" route. If we had what Mirko = > >> > >> > refers=20 > >> > to, then that'd open the door to another solution. > > > > And it would open the first door towards alienating linux distributions. > > > > Of course, we could say "and so what?". But that is our current primary > > way of getting our stuff to our users - so we shouldn't put obstacles in > > their way. > > > > Maven, ruby and stuff is all communities where there seem to be a strong > > tension with the linux distributions over issues like this. Let's not > > try to embrace that. > > Sune, > > with what I have suggested, there would be no difference for distributions > regarding ECM. > > Now, they have to get ECM installed and tell CMake where to find it. > > Then, they will have to get the ECM repo installed, and tell CMake where to > find it. > > For the offline case, I do not see a big difference. I don't want to > downplay the concerns, but I think the problem is manageable.
...depending on if/how we want to do that: we could start simple: search for ecm in KDECMakeSettings.cmake using the normal find_package() command, and if not found, download in some way. There may be a switch to disable that downloading. This would, at least in the beginning, not really be a generic way for cmake to fetch find-modules, it would be basically a convenience so that KDE developers can do find_package(tier0-KF5) ... do stuff instead of find_package(ECM) find_package(tier0-KF5) If it turns out to work good, it may turn into something more generic later. This would still not at all force ECM or tier0-KF5 as a dependency on any user of KF5 libraries. It even would not force ECM as dependency to all KF5 libraries, they could still disable it if wanted. Alex _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
