[KDE/Mac] Another QSP update for the OSX/CI system! + XDG_* vars on OSX?
Marko Käning
mk-lists at email.de
Sat Dec 13 19:46:49 UTC 2014
Hi folks,
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.
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?
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.
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.
> 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"?
> 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...
Greets,
Marko
[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
More information about the kde-mac
mailing list