Policy for Dependencies

[Alex Merry]

On Sunday, 18 October 2015 14:45:43 BST David Faure wrote:
> On Wednesday 14 October 2015 00:33:17 Christoph Cullmann wrote:
> > Lets see what David thinks about all that.
> 
> First: thanks everyone for waiting for my input, I appreciate that (I'm just
> one more voice though, no dictatorship here).

But a well-respected voice :-). Also, you're the closest thing we have to a 
"frameworks co-ordinator", in your role as release manager.

> The various global switches that have been suggested had unintuitive naming,
> so I will describe my thinking about them by using descriptions instead of
> actual names:
> 
> 1) A global switch "skip anything marked as optional" would be a very bad
> idea, it would even skip stuff that *is* available. I *think* this wasn't
> suggested, but I wanted to mention it just in case.

There may be a certain temptation to view it as an easy solution for those who 
want to build a stripped-down version of (part of) Frameworks without 
accidentally dragging in deps that happen to be on the builder's system. In 
practice, however, anyone doing this would probably want close control over 
the deps (rather than stripping out everything optional), and CMake already 
provides that via some magic variables to disable searching for packages.

> 2) A global switch "everything that can be optional, is now optional" sounds
> strange to me too. If it's optional, it's optional. (The description for
> the suggested KDE_ENABLE_MINIMAL_DEPENDENCIES added "this might lead to a
> loss of functionality". Well, that is *always* true when an optional
> dependency isn't found - otherwise it would be useless). Really, is there
> any sense in saying that a dependency is optionally optional? 
> 
> 2.1) I can see how the purpose was to let the default build be "with as many
> dependencies as possible". But for that maybe we can have a global switch
> for "fail if something optional was not found", for distros (and CI) to
> make sure they have *everything* enabled. Would this actually work for
> distro packagers? Do they have *all* the dependencies available?

I think it's more about the distinction (vague as it may be) between 
"optional" and "recommended" dependencies (FeatureSummary provides this 
distinction, but we very rarely use it). I think the idea is to be able to 
distinguish between "if this exists on your system, we will attempt to 
integrate with it" dependencies and "if we don't make use of this, a feature 
might be missing that users would expect to be there".

(As a side note, we may have that package A depends on package B *with 
optional feature C*. In particular, bits of Plasma may well require or 
recommend that certain Frameworks are built with certain features enabled that 
rely on optional dependencies. This is fine - see KArchiveConfig.cmake.in for 
how to deal with that.)

I think the idea was essentially to have an easy way to cause a build failure 
if the recommended dependencies weren't found (possibly with the default being 
the failure mode).

I'm fairly on the fence about the usefulness of that, TBH, particularly if 
your idea below solves the "bug reports from feature-deprived builds" issue.

> An argument was made that optional deps create more work for maintainers,
> who can't know, in bug reports, whether the dep was enabled or disabled
> (i.e. more configurations to handle). That is true. The solution isn't
> however to make everything mandatory. So we should solve this, after
> accepting the existence of optional deps. One random idea could be
> (automatically) installing a file, from each framework, with the list of
> optional deps that were found. Then when handling bug reports you can ask
> for that file -- or drkonqi could grab them all and concatenate them in a
> readable way.

This seems like a useful thing to do, especially when automating it via 
DrKonqi.

> 3) A global switch for a dependency, like "don't even look for dependency A
> in any of the frameworks" brings nothing IMHO. If it's optional and not
> found, we compile without.

As in my note in (1), I don't think this is something we should be setting, 
but rather than builders should be setting if necessary - CMake provides all 
that infrastructure, so we don't need to do anything (with the exceptional 
case of X11 on Mac, as you noted).

Alex