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