[KDE/Mac] Another QSP update for the OSX/CI system! + XDG_* vars on OSX?

[Ian Wadham]

Hi all,

On 14/12/2014, at 6:46 AM, Marko Käning wrote:
> I hope you’ve seen the post which I had forwarded to the other QSP thread here [1].
> It summarises what David wrote back then in July. Here is my thoughts about it:
> 
>> Wrong approach. XDG is a freedesktop thing which doesn't apply to Mac.

Pace David, I see nothing wrong in using the XDG approach on Mac with software
that has been *designed* to use XDG directories.  The real problem (on Mac) is
that some of the XDG default paths (esp. /usr and /usr/local) are used already
for Apple software and third-party software, free or proprietary.

MacPorts and Homebrew are collections of FOSS (Free Open Source Software),
of which KDE and Qt are a small part (believe it or not).  As such, MacPorts installs
all of its software separately from the stuff in /usr and /usr/local, i.e. in the /opt/local
area.  This avoids a whole heap of problems to do with builds, library linking, include
files and even licensing (I believe).

What I would suggest is that the MacPorts version of Qt5-Mac should use the XDG
approach, but with different default directories.  Then the $XDG_* variables would
still be free to use, but not in an end-user environment, where apps are started
from the GUI on the desktop.  IOW, we could benefit from them in OS X CI, downstream
testing, downstream development of KDE/Qt modifications, etc.

> It doesn’t apply, so we shan’t make use of said set of XDG env vars altogether?
> Not even, if they do not cause any harm, as they’re not applying to Mac at all?
> (David was dead set against ist, so I might not even ask this here on the list.)
> 
>> This should be fixed the other way around:
>> 1) finding out how Mac OS lets people configure the location for their files,
> 
> Have we not learnt from the
> 
> 	"[KDE/Mac] Thoughts on standard directories in Qt5 - QStandardPaths”
> 
> thread that env vars are rather a problem on OSX and should be used with care anyway?

Yes.  Environment variables are a threatened species in OS X's ever-tightening environment
and are extinct in the the most recent OS X versions, except for command-line work.

> So, if we use them, we mainly would do so for the CI system itself and for developers
> like Ian and René, but not for the end user.

Exactly.

> René has pointed out earlier that the use of XDG vars is not necessary on a normal
> OSX system, but to have this option for the future would be a bonus - especially if
> one thinks about extending its FreeDesktop.org support beyond the current xdg-utils.

Absolutely.

>> or if this isn't configurable, coming up with QT_* environment variables.
> 
> OK, so shall we create a new set of env vars basically replacing string “XDG" by “QT"?

QT_ would be IN-appropriate IMHO.  At most one could consider MP_ (for MacPorts) or some
such.  But why change the name?  XDG is naming an *installation approach* where different
categories go in different locations, as opposed to the OS X "bundling" approach.

The only problem is that we would have to use defaults that are not those in the XDG
standard, because they are already taken by Apple OS X and third-party files --- and also
we cannot use $XDG_* variables all the time in all versions of OS X, due to OS X restrictions.

>> 2) patching QStandardPaths to use these
> 
> That would be easy.
> 
>> 3) setting these vars in the CI scripts
> 
> I don’t know how much work that would require in your python scripts for the CI system.
> 
> Well, for now I haven’t dealt - as I initially intended - with the changes brought in
> by Qt5.4 regarding the new path types AppDataLocation and AppLocalDataLocation…
> I hope that’s excusable for the 1st discussion. :)
> 
> BUT _before_ we go now and _discuss_ the QSP patch [2] _openly_ on K-F-D I want us to
> have at least
> 
>  ONE application which finds all its files (data, config, themes) correctly!
> 
> Can we agree on that?
> 
>  I’d even give in and be happy with an application which has *proper* tests and
>  succeeds to 100%, if we can not make it run from the console work right now.
> 
>  The question is then only which app would be good enough for this, i.e. testing
>  access to all its data, config and whatever files…

You might need a *set* of apps, not just one, to cover all bases.

Cheers, Ian W.

> [1] http://mail.kde.org/pipermail/kde-mac/2014-December/002716.html
> [2] http://quickgit.kde.org/?p=clones%2Fwebsites%2Fbuild-kde-org%2Fkaning%2Fmp-osx-ci.git&a=blob&h=e3dd52cc903f2f2e86b9139b74c138ef19dc0cf1&hb=15f21bf549e5483d06602d6fe6b68dabb512eb88&f=patches%2Fqt5%2Fkf5-qt5%2Fpatch-qstandardpaths_mac.cpp.diff