[KDE/Mac] [OS X] adding a link module to all KF5 targets

[René J.V. Bertin]

On Tuesday September 29 2015 09:45:02 David Faure wrote:

Hi,

I appreciate your continued interest (and not having to send a 'bump' message :))

>You don't *really* need XDG on OSX. You need files to be found, it's just easier to do that by coying what we do on Linux/BSD ;)

Sure. But if it wasn't clear: for use in frameworks (sic..) like those provided by MacPorts those files have to be found in locations where non-Qt code will also find them. Which probably leaves little choice ...
BTW, was that an intentional slip-up, coy instead of copy? ;) Question is, what would be the real MacCoy? :)

>That is KStandardDirs, and I certainly do NOT want to bring that back. It would go exactly against "all apps use the same conventions"

I would say that it helps impose that "all apps use the same conventions", at least that's how I'd implement it.
>because apps using QSP and apps using KStandardDirs would do things differently.

I'm not suggesting to bring back KSD, much as having a patchable proxy class would make things easy as they were with KDE4. I'm really only thinking of something that provides a hook to modify QSP behaviour in a controlled fashion for *all* applications that belong to the class where the native QSP behaviour is not appropriate.

>And because it assumed XDG layout everywhere,
>which looks strange on OSX, looks a lot stranger on Windows, and is just not allowed on Android or iOS.

FWIW, I don't see why KSD could not have been rewritten to behave more appropriately?

>I meant "Version 6 of my Qt app didn't use KF5, version 7 used one widget from KF5, say KTextEdit, and my users lost
>all of their previous configuration because this brought in kcoreaddons, which toggled a global switch in QSP!!! You guys suck!!!" :-)

To which you could reply "but you asked for it by configuring your KF5 build to modify Qt's behaviour". Not changing stock behaviour by default has clearly always been a requirement for me.

>Hidden magic is good because it's hidden so people won't break it? I can't agree to this line of argumentation.

Didn't say it's good, and also didn't intend to hide through obfuscation. Rather, hide in plain sight, with a good ample description that would be a bit cumbersome in "user source code".
But,
>Anyway, meta discussions won't help, let's dive into specifics again ;)

>Hmm. You envision a world where a single packaging system controls all the Qt based libs.

Indeed, but I don't envision that as the only or even the centre of the universe. It just happens to be the world I live on ;)

>I suppose this is the case for Macports (and its alternatives like Fink, assuming people can't
>mix-n-match between the two)? Or can an app in Macports link to a lib from the "real" OSX
>(I guess I mean for instance /Library)?

MacPorts, HomeBrew and (AFAIK) Fink are comparable to things like Gentoo Prefix in that they attempt to be as self-contained as possible. It's not even their goal to provide libraries and middleware for use in whatever personal or professional projects users might have. They exist with the goal to make it easy to install (free) software, and strive for reproducible builds (which explains the goal of being self-contained). The only outside/system libraries that apps in MacPorts are supposed to link to are the system SDKs and a select few other libraries which would otherwise lead to circular dependencies. You can have MacPorts and Fink installed alongside each other (for users who know what they're doing); HomeBrew installs stuff into /usr/local and is thus more or less incompatible with anything else.
MacPorts also has the guideline to force applications and libraries to build against MacPorts dependencies instead of against any "embedded" copies of those libraries that might be shipped with the code. I'm even tempted to say that Qt is provided only so that Qt applications can all be built against the same, controlled version. Or at least that that argument is at least as important as the reduction of the disk footprint.
And yes, MacPorts uses a build and packaging system written in Tcl (running in a special tclsh); Fink uses Debian's packaging system and HomeBrew uses "recipes" written in Ruby . So all have ways to distribute specific patches (like my QSP patch, currently) and perform all kinds of magic .

Which also means that it's perfectly possible to implement some or all of the changes we're discussing here in the appropriate MacPorts ports.
That doesn't take away the fact that I need some guidance on how best to implement those changes ... and there is a MacPorts guideline that they shouldn't be the repository for upstream patches.

>If indeed this is about a self-contained world where all libs and apps should use the same paths,
>then we're back to the easiest solution: a Qt patch for Macports.
>Or the equivalent, an upstream Qt change which is enabled when configuring Qt for Macports.

Yes and no.
Yes, the required patch to QSP can be among the other patches MacPorts applies to Qt (there's a whole list, not all of them fixes to known generic issues).
And No, there still is the fact that pure Qt applications should be able to use native-style QSP locations. I'd have to discuss whether those locations should be really "stock" or whether at least some should point to things like /opt/local/Library, but that's an independent question.
The need for a QSP switch comes from this requirement that pure Qt applications distributed through MacPorts should behave as much as possible as those built against an "official" Qt install.

>If however this is about a mix-and-match world where some libs install files into XDG-like paths
>and some other libs install files into OSX-like paths, and some apps link to both of these libs,
>then neither a compile-time Qt patch nor your idea of a per-app behavior switch would work.

That's evident, but fortunately that is not the case. Libraries that are not part of Qt nor of KF5 and that use QSP will themselves be distributed through MacPorts (or Fink or ...) too, and can thus be subject to the appropriate patches. Which should be largely automatic because in my dream implementation it is the application (the end-point) that pulls in the module that will toggle QSP behaviour, and this will be effective for all libraries that link to the Qt install providing QSP. I won't even evoke the (im)possibility of mixing and matching different Qt installs ;) and thank goodness that QSP was not implemented using just a set of header files.

>I see in your followup that you want to be able to link to Qt from OSX (when I say that, I mean outside
>Macports), so it's not a fully self-contained world. But why do you want to be able to link with Qt from
>OSX but not with Qt-based libs from OSX? (I'm saying you're excluding that case because of your
>line above, "the packagers must ensure all libs are patched too"). That only works if all libs are
>from Macports, surely.

That's what I referred to above; I don't think MacPorts is really intended for this, and I doubt that a lot of support will be given for someone who runs into issues doing this (the question of support with free software is always a bit ... funny, or at least the line "we don't support this" is :)).
Of course, someone using MacPorts to install libraries and other stuff to build non-MacPorts applications must make sure that all components agree on all conventions, or face the consequences.
So yes, I've been known to use MacPorts this way. Nowadays, I find myself simply writing a "personal port" for such applications. Makes updating so much easier (including checking for the existence of newer versions), ditto for uninstalling, and one very quickly comes to appreciate MacPorts' activate/deactivate feature (with its support to keep multiple versions and variants "on standby"). That's so appreciable that I've even begun adapting my own ports for use on Linux :)

>A little bit too much magic for me, and I suspect for Qt devs as well.
>I could even imagine a case where an app would want per-call choice: if you want to
>use shared-mime-info from /usr/share/mime but still to save configuration into ~/Library/Preferences?
>Don't know if that makes sense.

It might; I'm much less convinced that it'd make sense to allow applications to differ in this.

>> There's a problem with that approach, though: Qt itself uses QSP
>
>Yes but that is a feature, not a bug :)
>Here's what I mean, in more details.
>
>There are two use cases for QStandardPaths (Config and Data locations, the rest is trivial).
>Case 1: a library installs a file in e.g. share/kxmlgui5/katepart/katepart5ui.rc and wants to be
...
>Case 2: writing and reading user-specific files, into writableLocation(). This matters a lot less IMHO.
>Whether you save stuff into ~/.config or ~/Library/Preferences, you can find it again later as long
>as nobody changes QSP behavior on you.

Yes, user-preferences and anything that's really specific either to Qt or to KF5 can go anywhere as long as everyone agrees on how to obtain that location.

>The qlogging.ini file that Qt is looking up falls into this category, it's a user file, not a file installed by Qt.
>However it could be considered confusing if you install *one* Qt on OSX, set up a qlogging.ini file for it
>(in ~/Library/Preferences), and it works for your OSX apps, but not for your Macports apps because
>they toggle QSP behavior *globally* so these apps are looking for this file in ~/.config.
>This is an argument in favour of a per-call switch! Qt using Native would keep it looking into the same
>location, no matter where apps want to save config files.

Heh, I have a feeling we're agreeing (without really realising it) and also both making things more complicated than necessary (but in different ways).

Your case 1 should be moot as long as everyone involved in that scenario uses the same QSP convention, libraries/frameworks and applications alike.
That's probably an argument in favour of implementing at least part of the modification in the build system, supposing that some of those files installed by libraries are installed (or have templates created) when the library is installed. If that's not feasible the idea of using a switch that gets toggled during the runtime initialisation becomes a lot less appealing.

As to your case 2: I don't really see any issues. It might be confusing if 2 different Qt installs behave differently say re: logging, but it might just as well be desirable. And however you turn it, there will always be differences between different Qt installs on the same host; they won't share plugins either. Which could in fact be an argument in favour of separating them as much as possible, also at the level of their configuration files (shared and per-user).

>I would just like to take one step back and make sure this is going into a direction that makes sense.
>Let's assume you can toggle QSP behavior to XDG somehow (per call or globally or whatever).
>What then? Macports users will have to set XDG_* env vars for the apps to work? I thought
>setting env vars wasn't an option?

No, the part of the patch that takes care of this is largely unmodified from what was presented on gerrit a while back. So there are hardcoded locations that point in the right direction and that can be overridden with XDG_* env. vars (e.g. in scripts and from the command line).

R