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

[Alexander Neundorf]

On Friday 22 February 2013, David Faure wrote:
> 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 :) ).

This is a question I've been pondering for a while: while on Windows we 
definitely need to be relocatable, how useful in reality is this when RPATH is 
involved ?

If I move libraries which have interdependencies from one custom location to 
another custom location, their RPATH will be wrong.
The same goes for other built-in full absolute paths.

If I move libs from one standard locations to another, e.g. /usr/ to 
/usr/local/, it may still kind of work, since they probably don't have any 
RPATH, but why should I do that ?

But being able to able to install a binary package in different prefixes would 
be a nice thing. RPATH *can* be solved by using $ORIGIN. It would be nice if 
we could detect that from within.
It is actually more or less necessary to make it possible to distribute custom 
binary packages.
I love how I can unpack the cmake binary packages from Kitware just anywhere 
and they work (for cmake it's easier, it's an executable).

> 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.

But that wouldn't be a serious problem I think.
There are solutions at least for Linux, FreeBSD, Windows and OSX. This would 
cover enough for the beginning, and other people porting to other OSs would 
probably also find something.
But finding that out for executables wouldn't actually help us.

> > 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.

Well, compile-time for the using project, not compile-time of the used 
project.
For the used project Foo, it is at runtime of the FooConfig.cmake file, it can 
query where it is located, check whether this is the original install 
location, and react to that.


...
> > 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

Yes, but isn't this what we are in for with getting rid of KDEDIRS/KF5DIRS, 
i.e. *fully* independent libraries ?

Alex