[fpc-pascal] Re: specifying the relative path to a file that is located in the same folder as the application bundle?

[Marco van de Voort]

In our previous episode, Jonas Maebe said:

(very old message I found in an anti-spam box, about paramstr(0) and
maintaining configuration files relative to it)

> In a sense, this is no problem because on Unix-like platforms you are  
> not supposed to use the fact where a binary is located in the first  
> place. You should only use the directory where the user was when the  
> binary was started (the present working directory), hard-coded paths  
> (e.g., relative to the system root, and relative to the user's home  
> directory), and paths inside configuration files stored in those  
> directores.

(

I think this policy is less formal, and more a result that in the past unix
applications used to be compiled specifically for each system. 

That it is a bit uneasy can be seen that binary distribution systems (like
RPM but also FreeBSD packages) can be used to setup alternative prefix dirs,
but have problems with finding support files locally also, be it in etc or
lib/, share/) Often this is worked around by having to set environment
variables to directories. This unfortunately means that you have to fix a
lot of them if you switch your PATH to a different prefix (e.g.
/usr/explocal/ instead of /usr/local to test an upgrade without deleting the
old)

For FreeBSD, the maintainer and I have brainstormed over to in the future at
least support the from source build better, since FreeBSD supports that.
This means that the prefix will be past from the ports system to the FPC
build system and then hardcoded into the binary. To avoid problems with
permissions and other freaky build dir setups, but also to have at least the
possibility to use exactly the same way on a couple of platforms I was
thinking to do this by passing the dir as a macro. the following bugreport
came from this discussion:

http://bugs.freepascal.org/view.php?id=12935 
)
> In case of bundled apps on Mac OS X this is different, which is why  
> there are special API's in that case to resolve the location of the  
> application bundle.

IMHO a superior way. (or maybe: a way that is at least tuned to binary-only
distribution)