On 2015-10-19 17:53, Christoph Cullmann wrote:
On Sunday, 18 October 2015 14:45:43 BST David Faure wrote:
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.
The way KArchive does that is interesting.
Would this be e.g. a way to say: Ok, we can compile configwidgets
without KAuth
if we skip the KCM part and then write that inside our config?
Yes, you could do that, and then Plasma, for example, could check the
variable that was set and complain if KConfigWidgets had been compiled
without the KCM. Downstream packages could also use FeatureSummary to
say something like "KFoo wasn't compiled with feature X, therefore
feature Y will be disabled for this package".
Atm e.g xmlgui has tremendous many dependencies that are often not
needed.
Boudewijn made a request to make more stuff optional which is imho a
bit too intrusive
but with not that much work some stuff could be removed:
https://git.reviewboard.kde.org/r/125530/
I would in addition see value in a "this is recommended" switch, that
leads
to compile failure if recommended stuff is not there or the switch is
toggled off.
That way, even without David's proposed improvements for the bug
reporting, I and
others could make more stuff optional, like audio in notifications,
without it leading
to bugs for the "standard" case of distro packages.
Well, this is the question: is it worth the extra complexity of
supporting such a switch (and it will introduce a reasonable amount of
complexity) if we have a way of including feature/dependency information
in bug reports?
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).
Yep, and btw., the way we do that at the moment for Mac is very
strange.
If you pass CMake no arguments, you get a strange warning that you
compile
without X11 support and might either turn this warning of or X11 on.
I would prefer no such info at all, given non-X11 is there the only
official way
to go, Qt not even ships any X11 backend per default. (that you can
turn it on
with the var is nice, but should not be promoted)
I was playing it safe, given the behaviour change. I'm open to removing
the warning a few releases down the line. Ideally, the warning would
only be shown if X would otherwise be found, but that's not really
practical.
Alex
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
