On Tuesday, October 13, 2015 2:20:31 PM CEST Christoph Cullmann wrote: > Hi, > > different take on that below: > > Hi, > > > >> On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote: > >>> Hi, > >> > >> thanks for raising this topic. I think it's very important that we have a > >> general strategy for frameworks and not have thousands of micro-fixes in > >> various frameworks. > > > > ;=) > > > >>> 1) "Normal" deployment like we do in on Linux => just installing it with > >>> all features if possible. 2) "Application Bundles/Installer" like we > >>> will have to do it on Win/Mac and 3rdparty Linux people will need to > >>> do. > >>> > >>> I think the easiest solution is to make stuff optional. That will avoid > >>> ugly "if (WIN OR APPLE OR ANDROID)".. hacks in CMake and allow people > >>> to still build stuff with that deps on that operating systems if really > >>> wanted.>> > >> Given from the no-X11 fixes I think that we should avoid all if (WIN OR > >> APPLE) as that: > >> a) is hard to maintain > >> b) doesn't scale > >> c) not testable for the devs working on Linux > >> > >> Given that it should be feature based and we should make as much usage of > >> the built in CMake features we have. I really like the approach we have > >> now found for X11 on OSX: disable certain find modules at a global > >> level. > >> > >> I think that is something which could be applied for more things. Control > >> through global ECM settings. This could if we don't want to have global > >> changes also through convenient command switches: > >> > >> e.g. cmake -DECM_BUILD_FOR_OSX_APPBUNDLE > >> > >> which then implies e.g. no phonon and no dbus and ... > > > > For X11 that might cut it, as it is non-sense to compile it on mac, but I > > doubt such > > global magic will cut it for other stuff like phonon or dbus. > > > > You might want to have both on mac and windows, too. > > > > If we start to make this global disabled, we will annoy people, too. > > In addition: If we want to have 3rdparty devs use our stuff, it must be > > possible to avoid these dependencies on Linux, too. > > > > I really would like to have the normal CMake strategy: non-required stuff > > is optional. > > > > For KNotifications thats even obvious, given its internals are build in a > > ways that this > > stuff is an internal "plugin". > > > > I don't think we need yet an other level of magic, beside things like "X11 > > on Mac/Win are non-brainers", > > which is not much more than we do with other global compiler/cmake flags > > specific for OSes. > > Ok, after the reasonable criticisms of making the sound stuff optional in > knotifications per default: > > Could we have some ECM switch like (name is just an example): > > option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies > from required to optional as possible, this might lead to a loss of > functionality." OFF) > > Based on that option, we can make stuff optional and we will have best of > two worlds: > > 1) no by accident loss of functionality and bug reports (like feared by > some, and I must confess that might be realistic) 2) an easy to use > solution for people wanting minimal dependencies as this is "one" switch > and it will work on all operating systems
I'm not sure whether it's the best solution. The problem you try to fix with it is distros breaking packaging. I agree with Martin K that this is a huge problem and that it will happen - since the automation of packages I also experienced that nobody looks at the output of optional dependencies and the packaging breaks. Given that I don't think we want an ENABLE_MINIMAL_DEPENDENCIES switch, but rather a mode which will break if not found during distro builds. Something like a "STRONGLY_RECOMMENDED" which is turned into "REQUIRED" if distros build (and maybe also kdesrc-build), but is optional if anybody else builds. But I'm not sure how this could be done. Anyway, long story short: I think we need the other way around. It should be optional by default, but should be turned into stricter requirements on the linux distro case. Cheers Martin
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
