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. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel