[fpc-pascal] fpc in symlinked directory

Michael Van Canneyt michael at freepascal.org
Wed Mar 26 13:21:22 CET 2014



On Wed, 26 Mar 2014, Tomas Hajny wrote:

> 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.

I didn't mean to imply this.

I reason within the frame of reference of Unix.

>>> 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.

The RTL does not 'uncover' anything. It uses strictly what the OS offers.

In the case of set/get CWD, the OS is queried/instructed.

So does Libc.

PWD is a convention, and IMHO belongs on the application level.

>> 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).

I was not speaking about compiler and debug info, but about the RTL.

As for paths used in the compiler: This is the application level. 
I don't think something needs to be done, but maybe the compiler developers think differently.

Michael.



More information about the fpc-pascal mailing list