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

[David Faure]

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