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