----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53939 -----------------------------------------------------------
What about QStandardPaths::findExecutable? Actually this one should look into libexec too (at least the equivalent KStandardDirs::findExe used to). - Aleix Pol Gonzalez On March 24, 2014, 10:52 a.m., Dan Vrátil wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117016/ > ----------------------------------------------------------- > > (Updated March 24, 2014, 10:52 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
