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.
> 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).
So we have:
<prefix>/${LIB_INSTALL_DIR}/kio/libexec/kioslave
${LIB_INSTALL_DIR} can be configured into a header.
"kio/libexec/kioslave" is fixed.
Leaves <prefix>.
This is then only needed in libkio itself, right ?
An executable can determine its own location at runtime.
The (to be) installed kioConfig.cmake can also determine its own location and
the location e.g. of kioslave at runtime.
Is there a way to find out where a library itself is located ?
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.
But then again, why not put them all together in kf5/libexec/ ?
Oh, is the obvious solution to have an executable kio-config which can be
queried ?
Or a KIODIRS env.var. ?
(basically: do we need those things we had for kdelibs now once for each
library ?)
> 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).
${LIB_INSTALL_DIR} will be different. So this shouldn't be a problem.
KDEInstallDirs.cmake takes care of that.
Alex
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
