How to announce new optional dependencies? [was: What KDE would like distributions to do]

[Matthias Klumpp]

2016-03-22 8:21 GMT+01:00 Martin Graesslin <mgraesslin at kde.org>:
> On Tuesday, March 22, 2016 3:31:10 AM CET Matthias Klumpp wrote:
>> One way to ensure new options get noticed is to enable them by default
>> and make cmake fail in case they're not supported and - in that case -
>> have the user explicitly disable them.
>> With that, the *BSDs will have a couple of -DFROBNICATE=OFF lines in
>> their package build scripts, but it also is immediately obvious that
>> way which features they should ideally implement. And for Linux,
>> distributions will investigate the build failure, find the missing
>> depndency or other requirement and rather satisfy it instead of
>> disabling the feature (and again, in that case we would have a visible
>> flag in the build script).
>>
>> It does make cmake scripts a bit more complex, but I think that's
>> absolutely manageable.
>
> hmm I fear that would making building from source for developers way more
> difficult. It would turn all optional things into build errors and one needs to
> hunt down the options to make it compile without them or figure out why their
> distribution doesn't have it.

Isn't the premise that the features in question *should* be enabled,
and that Linux distributions are providing these dependencies and the
switches to disable features are mostly for *BSDs? Under these
circumstances, having the build fail in case a missing dependency
isn't there seems reasonable.

> I just looked at the optional option in CMakeLists.txt of KWin and there are
> many which are just to make devs life easier. E.g.:
> * KF5Activities
> * KF5DocTools
> * XCB::ICCCM

Those should not be enabled by default and made to fail the cmake
process then, because you wouldn't expect distributors to enable those
features, right? If it's only very useful for developers, distros will
usually not enable it (unless exceptions apply).

> Then there are things like XCB::XInput2 which are not available on Debian
> distributions (it's experimental upstream). Turning that to required by
> default with a switch to make it optional makes the life of our devs on Debian
> distributions way more difficult.

For us it would be just one more -DFOO=OFF switch in debian/rules -
but again, is this a feature you expect all distributors to enable if
possible? If so -> make it fatal and add a switch to disable the
requirement if absolutely necessary. For a feature that's experimental
upstream, I would expect that this is not something which should be
always-on on distros, so leaving it completely optional until it
enters the "features I want to have enabled everywhere, unless
exceptional circumstances apply" set is fine, IMO.

> The "run kdesrc-build" becomes a "run kdesrc-build, check log file, figure out
> whether your distro of choice can provide the dependency, otherwise search for
> build option".

Jup, which is fine - your decisions as an upstream on whether to make
a feature required-by-default should include the availabllity in
distributions though - if only one distro can provide the requirement,
it's probably wise to reconsider making it required-by-default until
more distros ship with that feature.
In any other case, having people look through the log and explicitly
disable things which aren't found will lead to fewer surprises in the
long run. Questions like "why isn't X working?" can be answered easier
when you look at your configure flags and see that you disabled that
particular functionality.
Also, your general "fully supported" case will get better tests, since
people will install all the missing bits you intend the software to be
used with.

> At least in the case of KWin I prefer having an easy way for devs to build
> with the really optional things (like libhybris) being disabled by default and
> not having to hunt down the build options.

That's fine since libhybris is needed for a special formfactor and is
something I wouldn't consider the "general usecase". As soon as
libhybris becomes something you would expect to see when KWin is
present on a machine though, it should be on by default, as a hint to
distributors to make the feature you want on by default enabled by
default.

Cheers,
    Matthias