On Thursday 21 February 2013 18:38:46 Alexander Neundorf wrote: > On Thursday 21 February 2013, David Faure wrote: > > On Wednesday 20 February 2013 22:47:15 Alexander Neundorf wrote: > > > please have a look at the attached patch. > > > Ok to commit ? > > > > This looks good, but it will break the code, if you don't also update the > > code to look into these paths :) > > > > Don't forget to run > > perl -pi -e 's,kde5/service,kf5/service,g' `git grep -l kde5/service` > > perl -pi -e 's,kde5/libexec,kf5/libexec,g' `git grep -l kde5/libexec` > > in kdelibs (and plasma-framework?) when you commit. > > Ah, I didn't expect that to be hardcoded.
Yeah, it's a subdir, and without kstandarddirs we need to write down the subdir name, I don't have a better solution (of course KPlugin* encapsulates that for apps, but in kdelibs itself the subdir name appears in a few places). > How does > QStandardPaths::writableLocation(QStandardPaths::GenericDataLocation) > actually work, how does it determine the directory ? That line is basically $XDG_DATA_HOME, on unix. and standardLocations(GenericDataLocation) is $XDG_DATA_DIRS. > Via KDEDIRS ? KDEDIRS is dead in KF5. > In my other mail, with the code from kinit.cpp, this additionally has the > problem that it makes kdeinit non-relocatable, which is bad at least under > Windows (do we have kdeinit there) and also under Mac, where you typically > just want to drop the application somewhere. > I guess there we should also use something like QStandardPaths ? libexec is really a PITA, it's the one thing that doesn't fit into the idea of "QStandardPaths::something + subdir name", or into an existing env var like $PATH. I don't have a better solution for libexec stuff (at the kdeinit level we can always just ask the caller to pass a full path, but then, at the level of the caller, where we could know the lib name to use, we still have the issue of the non-relocatable binary due to hardcoded install prefix). Let's take a simpler example than kinit.cpp: kio/slave.cpp: const QString kioslave = CMAKE_INSTALL_PREFIX "/" LIBEXEC_INSTALL_DIR "/kioslave"; You made it something like CMAKE_INSTALL_PREFIX "/" LIB_INSTALL_DIR "/kio/libexec/kioslave" right? That gets rid of LIBEXEC_INSTALL_DIR, but it's still not relocatable. Should we rely on LD_LIBRARY_PATH (PATH on windows) in order to find it under <a lib dir>/kio/libexec/kioslave? But LD_LIBRARY_PATH isn't necessarily set for the libs themselves (RPATH or ld.so.conf are alternative ways to find shared libs). Another idea then: we could move libexec into the plugin dirs, and then use QT_PLUGIN_PATH? PREFIX/libXX/plugins/libexec/kioslave (in which case, there isn't really a need for per-lib subdirs). In both cases it means ugly iteration code every time we look for a libexec binary though. Unless QStandardPaths::findExecutable() looks into pluginsdirs/libexec, but since this is quite non-standard, I'm not sure the Qt developers will accept that. Well, that's the issue, there -is- no standard for libexec :( I'm not sure how this all works with multiarch stuff (but at least I'm suggesting places that contain binaries already, not XDG_DATA_DIRS). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by BlueSystems and KDAB to work on KDE Frameworks _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
