On Wednesday 26 August 2015 13:40:20 Volker Krause wrote: > On Wednesday 26 August 2015 13:15:15 Kevin Funk wrote: > > Heya, > > > > This is problem on Windows because the *final* installation location is > > not > > known at compile-time (obviously software is installed via installers, > > users can pick up the installation prefix). Of course this also limits > > the relocateability on other platforms, so it's not just a Windows issue > > per se. > > > > I've found this, which describes the issue in detail: > > https://www.mail-archive.com/kde-frameworks-devel@kde.org/msg01833.html > > > > Consider this code (kio.git): > > const QLatin1String libExecDir(CMAKE_INSTALL_FULL_LIBEXECDIR_KF5); > > const QString kioslaveExecutable = > > > > QStandardPaths::findExecutable("kioslave", {libExecDir}); > > > > Similar code exists in other frameworks. > > > > Problem: > > - Hard-coding the install path is a no-go (for sure on Windows) > > > > How can we solve this? > > > > Proposals: > > > > - Generic solution: > > - Add new API such as KSomeFittingClass::libexecPaths() > > > > which returns a list of candidates based on the platform > > > > - Then just do: > > `QSP::findExecutable("myexe", KSomeFittingClass::libexecPaths())` > > > > - Windows solution only (also less pretty): > > - In every place where CMAKE_INSTALL_FULL_LIBEXECDIR_KF5 is used: > > - Replace install prefix by QCA::applicationDirPath() via #ifdef > > > > Opinions? > > You might find useful building blocks for this in GammaRay. Instead of hard- > coding the absolute libexec dir there we compile in the relative path from > bin to libexec (as that depends on the exact install layout you configure > in CMake), and then combine that with QCoreApp::applicationDirPath() at > runtime. Makes the whole installation relocatable, as long as you don't > move things around within the install prefix itself.
Yep, thanks for this pointer. Didn't even know we had such code in GammaRay.
It's a bit more complex in KDE land because we have multiple levels of library
dependencies, each can be installed into different locations.
Assume on Linux
- KF5 installed into /usr
- KDevelop into $HOME/opt
When invoking `kdevelop` we can't just use
QCA::applicationDirPath()/../lib/libexec, b/c then we might not find
executables installed by KF5 in /usr/lib/libexec.
If we want to support this case, then we'd need to create a
KSomething::libexecPaths() method returning the following search path (in
order):
- Windows:
- Just QCA::applicationDirPath() (we control the install layout anyway)
- Unix:
- a list based on {DY,}LD_LIBRARY_PATH, each suffixed by libexec/
- then : As fallback: the hardcoded install prefix of KF5 as before
(otherwise we might not check /usr/lib/libexec at all, if installed there)
This is somewhat in line what David F. suggested in his initial mail, I think.
If this is not feasible in near future, I'd also be fine just fixing the
Windows-case by placing a few #ifdefs in KF5 code... (In fact, our shiny
KDevelop Windows installer already contains such patches)
> regards,
> Volker
Cheers
--
Kevin Funk | kf...@kde.org | http://kfunk.org
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
