[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: [KDE/Mac] Multiplatform frameworks
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2015-03-03 10:38:04
Message-ID: 1769271.RJtom32PQ2 () patux
[Download RAW message or body]

On Tuesday March 03 2015 17:09:21 Ian Wadham wrote:

> That looks as though it would work fine, but I still do not like that the choice of
> policy for standard paths is part of building Qt 5.  I would like to be working
> towards having one and only one one copy of Qt 5 in one Apple OS X system.

I don't think you can get around some form of choice when building Qt. Not if you \
want to be able to use a single Qt install for all possible use cases. In that case \
the code has to support all QSP policies, and then there are 3 choices one can make \
(given 2 policies): 1) default to policy 1 (stock)
2) default to policy 2 ("linuxy")
3) default to raising an error if the client application/code doesn't specify a \
choice

I think we don't want option 3, and if we accept the fact that despite the size of \
the K ecosystem it will probably remain a niche case on OS X we'll end up with \
hard-wiring a default choice to Qt's stock policy.

> Stefan's trick would allow you to choose your policy from outside Qt 5, using
> a QSP function such as proposed by Oswald Buddenhagen.  Or you could use
> a setenv in the "Stefanic" anonymous namespace and a getenv in QSP… ;-)

Even then, you'd want a fallback choice when no explicit choice is made "from outside \
Qt 5".

> Yes, config paths have to be nailed down too.  I have no strong feelings
> about /etc/xdg or ${prefix}/etc/xdg, except that we might as well keep things
> in the MacPorts family for now… :-)

Under MacPorts it'd of course be ${prefix}/etc/xdg .

R.
_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac


[prev in list] [next in list] [prev in thread] [next in thread]