Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix
Stephen Kelly
steveire at gmail.com
Sun Feb 28 08:50:51 UTC 2016
Aleix Pol Gonzalez wrote:
>> I think it would be good to have changes be better understood,
>> otherwise we end up with lots of mess. However, it looks like several
>> people really want this, and I don't want to stand in the way.
>
> I don't mind spending some time to explain it better.
>
> Currently what we're doing from ECM, by default, is to _guess_ where Qt
> will have placed things. Nowadays, `KDE_INSTALL_QTQUICKIMPORTSDIR` points
> to `${KDE_INSTALL_QTPLUGINDIR}/imports`. See `KDEInstallDirs.cmake:440`.
>
> If the Qt installation is configured to get the Qt imports to go to
> `/usr/lib/IKnowBetter/imports` and we don't change our guess, we'll get
> both the Qt directory and a `/usr/lib64/plugins/imports` directory where
> the cmake projects will naïvely place the plugins.
>
> An example of a case where we can see people suffering this (I found over
> a fast google search) is this:
> https://forum.kde.org/viewtopic.php?f=25&t=130498
Thanks for explaining!
So, this isn't being done at the request of packagers? I've asked a few
times if packagers have complained and no answer has come back. From now I'm
just going to assume that no packager has complained about the default of
the variable.
Instead this is motivated my issues like the one in the forum post?
What actually is the problem in the forum post? Will the plugin be found at
runtime? Does the location simply not match the expectations of the person
writing it, or is there some bad effect resulting from this?
If this is about users installing self-built things to /usr? Should that
person be installing things to /usr? My understanding up to now has been
'no, they should not'.
So, I still don't understand. Maybe this is about whether or not the plugin
can be found at runtime, but that has not been said, unless I missed it. I
could understand this discussion being tedious for you, and still I don't
want to stand in the way!
Thanks,
Steve.
More information about the Kde-frameworks-devel
mailing list