Policy for Dependencies

Aleix Pol aleixpol at kde.org
Tue Oct 13 12:40:21 UTC 2015


On Tue, Oct 13, 2015 at 2:20 PM, Christoph Cullmann <cullmann at absint.com> 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 think we're mixing different subjects here. One thing is being able
to be as portable as possible and another thing is to have few
dependencies. Dependencies are a portability problem as they make the
process a bit more complex, but also this process needs to be
standardized. The reason why dependencies are a problem when we port,
is because these pop when we as humble developers try to play the
packager role, and we're not used it it.

My proposal is that we should make sure which frameworks are viable on
each platform. If a framework is not viable on a platform (be it
because it's not an abstraction or because it doesn't make sense) then
other frameworks must either inherit the non-viability or make the
framework usage optional. And so should do applications that aspire to
be portable, which is by no means required.

I'm not sure though how acceptable is to drop functionality in favor
of just reducing the dependency list.

Aleix


More information about the Kde-frameworks-devel mailing list