On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 12:07:01 +0100 (CET)
Michael Van Canneyt <mich...@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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
