Policy for Dependencies

[Martin Graesslin]

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