[fpc-pascal] fpc in symlinked directory

[Michael Van Canneyt]

On Wed, 26 Mar 2014, Mattias Gaertner wrote:

> On Wed, 26 Mar 2014 12:07:01 +0100 (CET)
> Michael Van Canneyt <michael at freepascal.org> wrote:
>
>> On Wed, 26 Mar 2014, Mattias Gaertner wrote:
>> [...]
>>> You seem to think tcsh-specific behaviour is the correct way to do
>>> things. ;)
>>
>> Well, actually I don't think in such terms. I think that the system is right.
>> And the system (the linux kernel) has resolved the symlink to find the correct file/dir.
>> which is the only correct behaviour in my opinion.
>
> The system finds the right file by itself. That's why programs can work
> on a higher level.

>
>
>> [...]
>> Maybe they cater for it. I think this is a noble, but misplaced, intention.
>> If they would specify full pathnames, there would not be a problem.
>
> What problem do they have? /tmp/link is a valid file name.

Only because it is a full path. Then it doesn't matter whether you resolve or not.

But things like ../link may end up wildly on wildly different places depending 
on whether the start path is logical or physical.

Example:

/home/michael/projects/lazarus/lazarus.lpi
/home/michael/lazarus -> /home/michael/projects/lazarus
/home/michael/packages/synapse/laz_synapse.lpk

If I open 
/home/michael/projects/lazarus/lazarus.lpi
then the path to laz_synapse is
../../../synapse/laz_synapse

If I open
/home/michael/lazarus/lazarus.lpi
then the path to laz_synapse is (omitting the units/platform for simplicity)
../../synapse/laz_synapse

Specifying the latter to the compiler fails, because the compiler uses physical paths.

But specifying
/home/michael/packages/synapse/laz_synapse.lpk
will work correctly in both cases.

It gets complicated even more when the packages are in directories that have symlinks 
and I opened through the symlink or not.

>>> It compiles, but it creates wrong debugging info.
>>
>> Eh ? You didn't say anything about debugging info ?
>
> Yes, sorry. The wrong file names appear in error messages and debug
> info.
> Just add a syntax error to unit1.pas and compile once in /tmp/link and
> once outside. You see once the physical directory and once the
> logical.

So ? You just need to check the inode.

>> and the OS do the same.
>
> The problem is the following:
> The user opens /tmp/link/project1.lpr in the source editor and runs
> it. When there is a syntax error or when the debugger stops they report
> a source file name '/tmp/orig/unit1.pas' and the user wonders why.
> The IDE automatically opens the file '/tmp/orig/unit1.pas', but since
> it shows in the tab only the 'unit1.pas' the user may confuse that
> with the right file.

? it IS the right file. It is the SAME file, after all.

>
>> As a consequence, It will get rid of the annoying myfile.pp(2) when opening a source
>> file during a debug session.
>>
>> BTW: The Firebird database server also does this when resolving database
>> filenames. It checks the inode number. If it didn't, it would open the
>> same DB file twice, thinking they are different DBs - and corrupting them
>> in the process. So it needs to uniquely identify each file, to make sure
>> it opens each DB file only once.
>>
>> Which, again, I think is the only sensible behaviour.
>
> That's about writing to a file. I already wrote, that the source
> editor does that too. Some places of the IDE does not do the check.
>
> For instance:
> One include file used in different contexts. Depending on its file
> name different units use it and parse it differently. FPC reports the
> logical file name on an error and so the IDE knows the right context.
> The IDE opens the file two times and with different settings.

Which IMHO is totally misplaced behaviour.

Lazarus sometimes tries to be too clever. This is one of these times...

Michael.