[fpc-pascal] fpc in symlinked directory

Tomas Hajny XHajT03 at hajny.biz
Wed Mar 26 12:08:38 CET 2014


On Wed, March 26, 2014 11:25, Michael Van Canneyt wrote:
> On Wed, 26 Mar 2014, Mattias Gaertner wrote:
>> On Wed, 26 Mar 2014 09:10:09 +0100 (CET)
>> Michael Van Canneyt <michael at freepascal.org> wrote:
>>> On Tue, 25 Mar 2014, Mattias Gaertner wrote:
>>>
>>>>>
>>>>> So, FPC uses a system call to get the correct (resolved) CWD
>>>>> directory.
>>>>> This is the only guaranteed mechanism.
 .
 .
> cadwal: >cd /tmp
> cadwal: >ls -ld src1 link
> lrwxrwxrwx 1 michael michael    4 Mar 26 11:09 link -> src1/
> drwxrwxr-x 2 michael michael 4096 Mar 26 11:12 src1/
> cadwal: >cd link
> cadwal: >pwd
> /tmp/src1
>
> As you see, it has "resolved" the link.

Please note that this is not portable / consistent among platforms - if
you create a junction under MS Windows (which is more or less equivalent
to Unix links), the respective operating system API call returns the path
with the junction name rather than the real name.


 .
 .
> > Keep in mind that /tmp/link/unit1.pas and /tmp/orig/uni1.pas must be
> > treated as two different files and within one project you must use
> > only one of them.
>
> There you are wrong. They must be treated as the same file.
> They ARE the same file, after all.

They are obviously the same file, but the application may not be able to
detect it easily in all cases on all platforms (at least not using
platform independent API like our RTL). In my view, that's in fact the
point of links - allowing applications to work as if the real directory
setup was different from the reality. Assuming that the RTL should uncover
this is in my view not a good idea.

 .
 .
> That is why FPC resolves everything.
 .
 .

That probably depends on what you mean by "everything". E.g. references to
used units in debug information are stored as relative paths (and include
junction names if you used those when passing the path to the compiler).

Tomas





More information about the fpc-pascal mailing list