> On April 12, 2014, 10:48 a.m., Alex Merry wrote:
> > This is my preferred solution, and is hopefully only a temporary one.
> > However, I know David Faure doesn't like it, and (I assume) would rather
> > have a generic LIBEXEC variable.
> >
> > My view is that libexec should be used for stuff that's really internal to
> > a piece of software (like a framework), and so a libexec env var shouldn't
> > be necessary (except maybe for relocatability?), but the current situation
> > with drkonqi should hopefully be a temporary one (until 5.1 or something),
> > and so a specific var for unusual situations is reasonable.
> >
> > However, given that an objection has already been raised by the maintainer,
> > I'm not willing to give it a ship-it without his agreement.
I maintain my objection: while this particular issue might be temporary, the
fact that libexec path gets hardcoded into the compiled library makes things
impossible to relocate. PATH and LD_LIBRARY_PATH solve this for normal
executables and libraries, an equivalent is just missing for libexec.
My suggestion then is more precisely:
QFile::decodeName(qgetenv("LIBEXEC_PATH")).split(':') and pass that list to
QStandardPaths::findExecutable(), which can take a list of paths to check into,
as the second argument. Nice and easy. And later we can do the same in all
frameworks that look for something in libexec (with a fallback to the builtin
path).
- David
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117016/#review55497
-----------------------------------------------------------
On April 9, 2014, 8:47 a.m., Dan Vrátil wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117016/
> -----------------------------------------------------------
>
> (Updated April 9, 2014, 8:47 a.m.)
>
>
> Review request for KDE Frameworks.
>
>
> Repository: kcrash
>
>
> Description
> -------
>
> Since KCrash is a framework that relies on DrKonqi binary being provided by a
> 3rd party software (kde-runtime), it should not make assumptions regarding
> location of the utility.
>
> This patch makes KCrash to look for drkonqi binary first in $PATH, then
> falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch
> it's possible for distributions to ship KDE Frameworks in normal prefix
> (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance.
>
>
> Diffs
> -----
>
> src/kcrash.cpp 87163cc
>
> Diff: https://git.reviewboard.kde.org/r/117016/diff/
>
>
> Testing
> -------
>
> - Installed KCrash into /usr prefix
> - Installed drkonqi from kde-runtime master to /opt/kde5 prefix
> - started broken application
> - no "could not find drkonqi" warning anymore
> - crashed application, got drkonqi window
>
>
> Thanks,
>
> Dan Vrátil
>
>
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
