libexec (Re: "kde5" or "kf5" ?)

[David Faure]

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, faure at kde.org, http://www.davidfaure.fr
Sponsored by BlueSystems and KDAB to work on KDE Frameworks