Policy for Dependencies

[Christoph Cullmann]

Hi,

I have now all my patches in frameworks to build some KWrite/Kate application
bundle that doesn't instantly crash (and windows builds seem to be nicer, too,
without that many problems to locate assets).

My last patch missing makes still stuff optional:

https://git.reviewboard.kde.org/r/125616/

Could we come up with some "have a global switch in ECM or not" and if not,
how to do such things?

Greetings
Christoph

----- Am 14. Okt 2015 um 16:03 schrieb Alex Merry alex.merry at kde.org:

> On 2015-10-13 16:54, Christoph Cullmann wrote:
>> Hi,
>> 
>>>> 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.
>>> I would be happy with such an solution, too.
>>> But I am not that optimistic that this is easy to achieve, how to
>>> ensure all
>>> distros
>>> turn this magic on?
>>> 
>>> The opposite direction at least would avoid the distro breakage and
>>> still allow
>>> optional compiles for the "3rd party wants less dependencies" or
>>> "other platform
>>> wants
>>> less dependencies" use case.
>>> 
>>> Even if not optimal, some ENABLE_MINIMAL_DEPENDENCIES would in my eyes
>>> still
>>> better than
>>> the current situation, were either we have optional stuff that will
>>> make us
>>> unhappy because
>>> of broken distro packages or the devs unhappy that need to patch
>>> dependencies
>>> out on their own.
>>> 
>>> e.g. Kåre did in most cases exactly that for the Windows build
>>> (git at git.kde.org:scratch/sars/kate-windows),
>>> which IMHO is sad.
>> 
>> My ECM proposal would be the following:
>> 
>> 1) add to KDECMakeSettings.cmake:
>> 
>> ################ Dependencies mode ####################################
>> 
>> if(KDE_SKIP_FULL_DEPENDENCIES)
>>     unset(KDE_FIND_REQUIRED_OR_OPTIONAL)
>>     set(KDE_TYPE_REQUIRED_OR_OPTIONAL "OPTIONAL")
>> else()
>>     set(KDE_FIND_REQUIRED_OR_OPTIONAL "REQUIRED")
>>     set(KDE_FTYPE_REQUIRED_OR_OPTIONAL "REQUIRED")
>> endif()
>> 
>> 2) use that e.g. in knotifications:
>> 
>> find_package(Phonon4Qt5 4.6.60 ${KDE_FIND_REQUIRED_OR_OPTIONAL}
>> NO_MODULE)
>> set_package_properties(Phonon4Qt5 PROPERTIES
>>    DESCRIPTION "Qt-based audio library"
>>    TYPE ${KDE_TYPE_REQUIRED_OR_OPTIONAL}
>>    PURPOSE "Required to build audio notification support")
>> 
>> That would at least make people happy that want no missing features and
>> allow
>> me and others to work on minimizing the dependencies without annoying
>> others.
>> 
>> If there is some magic way to set KDE_SKIP_FULL_DEPENDENCIES for
>> non-distro builds,
>> that could be added later inside KDECMakeSettings.
> 
> I'm not a fan of the variable names - in particular, I think your
> original idea for an option name was better than
> "KDE_SKIP_FULL_DEPENDENCIES" - the existing KDE_SKIP_* variables are
> meant as things project authors define if they only want part of the
> module functionality, rather than as something for users/packagers to
> set. KDE_FIND_REQUIRED_OR_OPTIONAL also tells me essentially nothing
> about *why* it might be REQUIRED or optional when I'm reading the
> source.
> 
> That said, I'm on board with the overall idea.
> 
> Alex
> 
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

-- 
----------------------------- Dr.-Ing. Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann at AbsInt.com
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234