New BinReloc patch

[Arend van Beelen jr.]

On Monday 19 April 2004 17:54, Waldo Bastian wrote:
> On Mon April 19 2004 17:44, Arend van Beelen jr. wrote:
> > Okay,
> >
> > as Thiago suggested the logic in the functions is now simply skipped on
> > non-Linux platforms, so the functions will immediately return
> > QString::null there. Also, as Waldo pointed out, the change to
> > KIconLoader appeared redundant, so I removed it and KIconLoader is no
> > longer affected. Finally I also made a clear distinction between
> > [application|library][Path|Prefix] as the old method was quite flawed :)
> > Waldo, are you still against adding this to the API?
>
> Yes, I don't see the need for these functions and their availability makes
> it more likely that people will write applications that don't work on
> non-linux platforms.
Well, the need for these functions is clearly there, they help in making 
applications binary relocatable, which is a requirement for use with 
autopackage. Right now, developers from Apollon, amaroK and Kile are 
interested in this. Not having this functionality will make it impossible to 
have distribution-neutral binaries or binaries that can be installed for one 
user only.
Now the exact use of these functions is to locate data files that might be 
installed with the binary, but not in a standard location. This location can 
then be used as an *additional* location to find its files, but such a 
location is not guaranteed to be found. Therefore, if the application can't 
find its data files in the ordinary location(s) it might be able to fall back 
on this one. The ultimate effect is that applications can have an extra 
fallback directory to find their files. A directory that currently can't be 
located at all. So if an application depends on this function to find its 
files, it will fail to find 'm on non-Linux systems. However, the application 
would fail right now as well as there's currently not even a way to /try/ to 
find that directory currently. So these functions provide an extra fallback 
on Linux but don't break anything on other platforms. Of course an 
application might decide to only look in this directory for its files, but 
that would be very illogical as the functions are documented to possibly 
return QString::null.

My last proposal would be to drop the functions altogether and only do the 
initialization in the constructor of KStandardDirs as done in the patch. This 
won't add any calls to the API, but simply won't work when used from other 
libraries and might make it harder for applications that need to find their 
location themselves for which they don't use KStandardDirs (though if such an 
application would depend solely on these functions, then yes, they might 
become non-portable. But you can't prevent such a corner case without 
removing the library support).

Greets,
Arend jr.

-- 
Arend van Beelen jr.
http://www.liacs.nl/~dvbeelen

It's a wonderful life - if you can find it.
-- Nick Cave & The Bad Seeds