On Thursday 27 August 2015 00:14:50 Kevin Funk wrote: > 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.htm > > > l > > > > > > 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.
Indeed.
> 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/
That will miss system search paths (including manually configured ones) and
far more importantly R[UN]PATH, no? When implementing this, you might find
useful building blocks for the library search path logic in elf-dissector,
Linux-only unfortunately. GammaRay recently got RPATH resolution for Mac,
might also come in handy.
However, at that point it might become more reliable to look at the location
of the actual loaded library, ie. like QCA::appDirPath(), just for the DLL
rather than the executable. Then you would just be re-using the lookup logic
of the dynamic linker.
This would be very platform-specific code though, GammaRay has implementations
of this for doing it on external processes (in the probe ABI detector), there
might be more efficient ways to do it in-process, on some platforms at least.
regards,
Volker
> - 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
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
