[KDE/Mac] Another QSP update for the OSX/CI system! + XDG_* vars on OSX?
iandw.au at gmail.com
Sun Dec 14 00:07:22 UTC 2014
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 .
> 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.
> 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"?
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  _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.
>  http://mail.kde.org/pipermail/kde-mac/2014-December/002716.html
>  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