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). 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. 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? :-P 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? The discussion on 2) vs 2.1) is almost like discussing the default value of the same option, except that with 2) every framework would still be able to have always-required, required-or-optional, and always-optional dependencies. You could say that's extremely flexible, on the other hand I wonder if it's not too much choice (i.e. too much complexity). E.g. the kwallet dependency in KIO now is optional, therefore it's optional, end of story. Yet we don't want distros compiling KIO without KWallet, but aren't we optimizing for the wrong thing? I mean, I didn't hear about KF5 packages being wrong because of missing deps (i.e. if it happened, it must have been fixed pretty quickly). So unless someone proves the contrary to me, I would say this whole 2/2.1 discussion is moot, the tools that we have (to express optional dependencies) do work, we just need to work towards making more stuff optional, like Christoph is doing. 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. 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. 3.1) As a special case of that, I do however see the usefulness of "don't even look for X11" as a global switch, because of the OSX case where it might be lying around and we don't want to use it. It's a special case because it's an exclusive switch (AFAIK you either use cocoa or X11, not both), unlike most of our other dependencies. 3.2) More generally *if* distributors want a way to express "don't even look for dependency A, because I might have it installed but I don't want my packages to depend on it", then I have nothing against that. And then the X11 case can be just one instance of that. I'm not replying here to the part of the thread around packaging for Windows and Mac, that's a separate discussion. I note, however, that Christoph's patches which make more use of .qrc files, are the best way to solve some of these issues. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
