On Saturday November 21 2015 12:59:40 David Faure wrote:
>I still don't see why you can't just patch Qt on macports (given that you're
>already patching it anyway) rather than having to add something to each and
>every link line in KF5,
That would mean having 2 different Qt5 installs in MacPorts; one for pure Qt
applications that are expected to behave "natively", and one for KF5 apps and
the occasional pure Qt5 app that should behave in compliance of XDG because
it's supposed to interact with KDE4 and non-Qt applications from the
Freedesktop universe.
That's a solution I never really considered, and which I think would never make
it into MacPorts.
It's already bad enough in that area: after months of silence while I prepared
the Qt4 and Qt5 ports to enable concurrent installation the official (but not
exclusive) maintainers of those ports both woke up and decided to do things
their way. And of course by then they felt it was too much work to go over each
and every change I made, and apparently unthinkable even to simply test my
implementation. So now there's the official "qt4-mac" port, I have my own with
a different install layout (I haven't bothered submitting that one), there's
the official "qt5" port and my submitted "qt5-kde" port which has the XDG patch
and an install layout that like the one from the old exclusive ports and what's
usual under Linux (i.e. stuff in ${prefix}/share, ${prefix}/include/qt5 etc.
rather than the whole bunch hidden under ${prefix}/libexec/qt5).
I probably don't need to modify each and every link line in each and every KF5
cmake file, despite the fact that there is no single "Tier 0" framework.
Theoretically it ought to be enough to add the activator only to the Tier1
frameworks, though that would probably increase the likelihood that QSP gets
called before it's toggled. I've also noticed that CMake apparently pulls in
certain link dependencies recursively; I've seen the activator dylib appear in
the link list of objects where I left it out explicitly (plugins, for instance).
>but let's have that discussion separately on k-f-d.
You got it :)
R.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
