On Thursday 21 February 2013 19:20:56 Alexander Neundorf wrote: > On Thursday 21 February 2013, David Faure wrote: > > 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? > > This would be the simple way, yes.
How about we make it CMAKE_INSTALL_PREFIX "/" LIB_INSTALL_DIR "/libexec/kioslave"? Then on Windows, we can just request that PATH contains that (unique) libexec directory, and we have achieved our goals: relocatability (assuming that word exists :) ). And the good thing about this solution is that it requires very little code each time a libexec executable is queried (no iteration over some list of dirs, just full-path and fallback to QStandardPaths::findExecutable). As you suggest below we could make that CMAKE_INSTALL_PREFIX "/" LIB_INSTALL_DIR "/kf5/libexec/kioslave" but that kf5 directory will have nothing else than libexec in it, so there isn't much point. Or maybe this should be kf5-libexec for "namespacing". > An executable can determine its own location at runtime. Not portably, AFAIK. > The (to be) installed kioConfig.cmake can also determine its own location > and the location e.g. of kioslave at runtime. That sounds like compile-time, not runtime. > Is there a way to find out where a library itself is located ? Not that I know. > Or are we now back at the kde4-config solution. kf5-config could be queried > about its location, and it could figure out where kio is. Using QProcess? This sounds extremely slow. *-config is for scripts, not for library code. Whatever that program does internally, just do that in the lib. > But then again, why not put them all together in kf5/libexec/ ? Yes. This at least makes a few things simpler, after all. > Oh, is the obvious solution to have an executable kio-config which can be > queried ? QProcess again? See above. > Or a KIODIRS env.var. ? > (basically: do we need those things we had for kdelibs now once for each > library ?) This sounds like extremely cumbersome setup. We have enough env vars to set already, I would really like to avoid having to require more. Especially since we have an obvious way to make it work on systems where you don't need to relocate the stuff: CMAKE_INSTALL_PREFIX. Let's also make it work on Windows, but not by paying the price on Unix with more env vars (and having to write loops everywhere). -- 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
