[fpc-pascal] fpc in symlinked directory

[Michael Van Canneyt]

On Wed, 26 Mar 2014, Mattias Gaertner wrote:

> On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
> Michael Van Canneyt <michael at freepascal.org> wrote:
>
>> [...]
>>> 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.
>
> When a user tells a program to open file /tmp/link/unit1.pas,
> he expects it to work with /tmp/link/unit1.pas
> not /tmp/orig/unit1.pas. Almost all editors do that and so does Lazarus.

I am not arguing with this. 
You can store the filename with the path as specified by the user. 
Relative if you want, for files within the same project.

But I am arguing that when passing filenames/paths to other tools 
(including the compiler), you should always specify full filenames.

This way, you don't need to worry about the distinction between physical/logical.

>> That is why FPC resolves everything.
>
> Not true.
> For example when I leave out the 'cd /tmp/link' and my cwd
> is /home/mattias, then fpc creates the debugging info
> "../../tmp/link/unit1.pas".
>
>
>> /proc/self/cwd does the same: it resolves the directory.
>
> This is the physical cwd.

Yes. It is the only one that makes sense.

>
>
>> cadwal: >ls /proc/self/cwd -l
>> lrwxrwxrwx 1 michael michael 0 Mar 26 11:18 /proc/self/cwd -> /tmp/src1/
>>
>> So I still think that the FPC behaviour is the only correct behaviour.
>
> What is incorrect with using the logical cwd?

That passing relative paths such as ../../xyz  become ambiguous, 
since they rely on the receiving tool obeying the same convention 
as the sending tool.

>> And likewise, I think that Lazarus is still wrong using relative paths.
>
> AFAIK the only issue with symlinks are the '..', as this works on the
> physical parent. There is no problem with a relative path like
> 'foo/bar'.

Exactly. Lazarus specifies ALL links to required packages as relative paths.

They go horribly wrong in the presence of symlinks.

> I don't see how absolute paths can work platform independently.

But they don't have to be platform independent ?

I have a project A, depending on package B. 
I don't have to specify a path in the dependencies.

Lazarus KNOWS where package B is located on my current system.
So, it can specify the full path. 
Whether this path contains symlinks or not is then totally irrelevant.

However, if lazarus wants to specify a relative path, it must calculate this.

Then suddenly, the difference between "logical" (in fact, badly chosen name, it should be 'historical" IMHO) 
and pĥysical path becomes relevant, and depends on how the 'receiving' tool reacts on this difference.

Ergo: Don't use relative paths, always absolute, 
when passing paths to other tools. All problems are solved.

If I MANUALLY specify some path as a relative path, only then Lazarus 
may assume that I know what I am doing, and pass the path unmodified to external tools.

I don't see what the problem is with this reasoning. 
I am in fact surprised that you can think any other way...
(but that is my shortcoming ;) )

Michael.