libexec (Re: "kde5" or "kf5" ?)

[Alexander Neundorf]

On Saturday 23 February 2013, David Faure wrote:
> On Saturday 23 February 2013 10:43:51 Alexander Neundorf wrote:
> > Well, it would be great if with KF5, if I install some library which
> > needs to  find its own files, it would find them without needing the
> > help from environment variables.
> 
> You're forgetting the other cases where files have to be found, which are
> not "a lib finding its own files".
> 
> In many many cases (other than libexec), the files have to be found
> "externally".
> The icon loader code needs to find the icons.
> The mimetype code has to find the mimetype definitions.
> kconf_update has to find update files.
> Workspace autostart has to find autostart files.
> etc. etc.
> 
> XDG_DATA_DIRS does this. Magic determination of a lib's own prefix inside
> that lib's code doesn't.

Doesn't it as long as everything is in the same prefix ?
(that would be the case if I would build a bunch of kf5 libs for "my" 
hypothetical commercial app, and ship them with it, they would all go into one 
common directory)
This would extend the it-just-works from libraries without any extra files to 
libraries which have extra files.

> But yes, if you install libkarchive, you don't need any of this. It's just
> code, no data files and no external processes, so your "plug and play" wish
> is granted, it's just like any other "pure library". The commercial
> developer can just put karchive.dll next to QtCore.dll (and IIRC, if
> that's in the same dir as the .exe, no $PATH needed).
> 
> However when you install KIO, helper binaries have to be found, config
> files have to be found, icons have to be found, plugins have to be found
> (kioslaves), etc. The current solution (QStandardPaths) is to either
> install that into standard directories (/usr or /usr/local on Unix,
> "Application Data" on Windows), or to set additional XDG env vars (on
> Unix), for custom prefixes. If you have a specific idea on how to improve
> that I'm listening, but "it should work out of the box" is just a wish. I
> guess QStandardPaths could also look in the application directory, on
> Windows, to help with the "everything in the same directory" case.
> But on Unix, using the lib's own dir and then "going up" seems very very
> fragile and non-standard to me. I don't see the full solution you have in
> mind there.

At configure/cmake time, we can configure e.g. the data install dir, the lib 
install dir and the install prefix into the library.
At that point, we can check whether both are installed into the same prefix, 
independent of whether absolute or relative paths are used for installing.

So we can configure the relative path to the data and to the library into the 
library, so we have then e.g. "share/kio/" and "lib/<multiarchdir>/" in the 
library.
At library runtime we can find out the location of the library, check that it 
contains the configured relative library install path, and if so, remove that 
part, and we have the install prefix at library runtime.
(I can create an example for that)
As long as nobody messed around manually with the installed files, appending 
the configured data install dir to the calculated install prefix will result 
in the correct directory to the data.

For the case that the files are not in a common prefix, or that they are in a 
standard location, like /usr/share and /usr/lib, we may do it differently.

This is more or less the same mechanism as cmake's Config.cmake files handle 
references to other files or directories.

Alex