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
Sat Feb 27 11:33:23 UTC 2016
> On Feb. 24, 2016, 7:06 p.m., Stephen Kelly wrote:
> > Hi Aleix,
> >
> > I'm not familiar with the 'tiny mess'. Can you say what it is? I would expect the libs go in the same place, but maybe the plugins are affected by this? Can you be more specific?
> >
> > Thanks,
>
> Aleix Pol Gonzalez wrote:
> Well, Qt might be installing things in `$prefix/lib` and cmake in `$prefix/lib64`. In fact, Qt by default installs plugins in `$prefix/plugins` (which looks really odd, I agree).
> In any case, if it's meant to go to the same place, let's just ask Qt where to go.
>
> As you can see, all of the distros are already specifying this: (and they don't need to in fact, because it's the same prefix)
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kcoreaddons
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pkg-kde-tools/wily/view/head:/datalib/kf5_flags
> https://pkgs.fedoraproject.org/cgit/rpms/kf5.git/tree/macros.kf5
>
> Nicolás Alvarez wrote:
> I don't think "all distros set it" is a valid argument for changing a default, otherwise we would be setting `CMAKE_INSTALL_PREFIX=/usr` by default too.
>
> Stephen Kelly wrote:
> I agree with Nicolás that this seems wierd. Are packagers complaining about having to set this?
>
> Also, I don't think I've seen enough specifics about the impact this has. What moves where etc.
>
> Aleix Pol Gonzalez wrote:
> 99% of our users use a setting that we don't enable by default? It's definitely something to take into account.
>
> In fact, if the creator of a system decided that Qt plugins go to /usr/heaven/plugins, I don't really see why we should override the decision and ask the user to configure each project specifically. I understand this wouldn't make sense if they weren't sharing a prefix, as it's a complete different thing.
>
> An example is my installation. Qt decided to put the plugins in `$prefix/lib/plugins`, cmake/ecm decides to put them in `$prefix/lib64/plugins`. I get 2 Qt plugin directories for no reason.
>
> Stephen Kelly wrote:
> Sorry, just so I understand - The '99%' is referring to packagers creating distro packages?
>
> Do we want to make 'create a distro package' the primary/default case in kde buildsystems? Genuine question. Otherwise I don't understand your point here I'm afraid. That would indeed mean we should set CMAKE_INSTALL_PREFIX=/usr. Perhaps there are other things we should set too. If you're suggesting we should do that, then maybe we really should. Is that the suggestion?
>
> I'd still like to see a list of what changes. What moves where etc, as a result of this. You mentioned $prefix/lib/plugins to $prefix/lib64/plugins . Is that everything? It's only plugins that are affected?
>
> Aleix Pol Gonzalez wrote:
> `CMAKE_INSTALL_PREFIX=/usr` would be a whole different story, because we'd be deciding on where the project is installed. The important thing is that if the user decides that his project and Qt share the same prefix, those should get plugins (and FWIW, anything that will be looked-up afterwards by Qt) in the same place, by default.
>
> Namely, that is that we're making sure is the same:
>
> * KDE_INSTALL_QTPLUGINDIR: `qmake -query QT_INSTALL_PLUGINS`
> * KDE_INSTALL_QMLDIR: `qmake -query QT_INSTALL_QML`
> * KDE_INSTALL_QTQUICKIMPORTSDIR: `qmake -query IMPORTS_INSTALL_DIR`
>
> Nicolás Alvarez wrote:
> Oh, what if the user *doesn't* have his project and Qt in the same prefix? Eg. Qt in /usr (system-provided) and his project in ~/local?
>
> Stephen Kelly wrote:
> > Namely, that is that we're making sure is the same:
> > KDE_INSTALL_QTPLUGINDIR: qmake -query QT_INSTALL_PLUGINS
> > KDE_INSTALL_QMLDIR: qmake -query QT_INSTALL_QML
> > KDE_INSTALL_QTQUICKIMPORTSDIR: qmake -query IMPORTS_INSTALL_DIR
>
> Thanks. This is specific and we can have a discussion about them. Too late in this evening for me now though.
I tried to figure out what the differences are in terms of paths, but I couldn't figure out what KDE_INSTALL_QTPLUGINDIR, KDE_INSTALL_QMLDIR, KDE_INSTALL_QTQUICKIMPORTSDIR resolve to and how that changes.
Also, my question about whether packagers are complaining about having to set that variable wasn't answered.
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.
- Stephen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127169/#review92739
-----------------------------------------------------------
On Feb. 24, 2016, 5:09 p.m., Aleix Pol Gonzalez wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127169/
> -----------------------------------------------------------
>
> (Updated Feb. 24, 2016, 5:09 p.m.)
>
>
> Review request for Extra Cmake Modules, KDE Frameworks and Albert Vaca Cintora.
>
>
> Repository: extra-cmake-modules
>
>
> Description
> -------
>
> Make Qt and ECM-based projects use the same directory sctructure (i.e. where plugins are, libs, etc.) by default. Otherwise it creates a tiny mess that might be controlled but usually won't.
>
> In the end, otherwise, people need to keep adapting their systems with environment variables anyway. All distros end up setting always this setting as ON, as well as brave developers who don't have separate prefixes for Qt and KDE.
>
>
> Diffs
> -----
>
> kde-modules/KDEInstallDirs.cmake ebd48fa
>
> Diff: https://git.reviewboard.kde.org/r/127169/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Aleix Pol Gonzalez
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20160227/a2ee5045/attachment.html>
More information about the Kde-buildsystem
mailing list