Paths to internal executables (c.f. libexec) hard-coded

[Kevin Funk]

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 | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150827/25d767f6/attachment.sig>