Great news!
I'll comment it to Pascal Game Developer community and in Club Delphi
too.
Guillermo "Ñuño" Martínez
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
On Wed, 26 Mar 2014, Marc Weustink wrote:
Michael Van Canneyt wrote:
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 15:33:38 +0100 (CET)
Michael Van Canneyt wrote:
[...]
So ? You just need to check the inode.
Is there a function to list all files pointing to an ino
Michael Van Canneyt wrote:
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 15:33:38 +0100 (CET)
Michael Van Canneyt wrote:
[...]
So ? You just need to check the inode.
Is there a function to list all files pointing to an inode?
Actually, you just need to know if 2 fil
On Wed, March 26, 2014 23:52, Mattias Gaertner wrote:
> On Wed, 26 Mar 2014 23:19:57 +0100
> "Tomas Hajny" wrote:
>
>> On 26 Mar 14, at 23:05, Mattias Gaertner wrote:
>> > On Wed, 26 Mar 2014 18:47:06 +0100 (CET)
>> > Michael Van Canneyt wrote:
>> >
>> > >[...]
>> > > The compiler does not do any
On Thu, 27 Mar 2014 08:16:11 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> > I described the situation from a user's pov.
> > Somewhere it should be documented.
>
> I will do so.
Thanks.
> >
> > BTW, is there already a RTL function to resolve a file name?
>
> fpReadLink ?
>
> Or do you m
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 18:47:06 +0100 (CET)
Michael Van Canneyt wrote:
[...]
The compiler does not do anything special: it determines its current
working directory using the RTL, meaning it gets the resolved current
working directory.
I described
On Wed, 26 Mar 2014 23:19:57 +0100
"Tomas Hajny" wrote:
> On 26 Mar 14, at 23:05, Mattias Gaertner wrote:
> > On Wed, 26 Mar 2014 18:47:06 +0100 (CET)
> > Michael Van Canneyt wrote:
> >
> > >[...]
> > > The compiler does not do anything special: it determines its current
> > > working director
On 26 Mar 14, at 23:05, Mattias Gaertner wrote:
> On Wed, 26 Mar 2014 18:47:06 +0100 (CET)
> Michael Van Canneyt wrote:
>
> >[...]
> > The compiler does not do anything special: it determines its current
> > working directory using the RTL, meaning it gets the resolved current
> > working direc
On Wed, 26 Mar 2014 18:47:06 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> The compiler does not do anything special: it determines its current
> working directory using the RTL, meaning it gets the resolved current
> working directory.
I described the situation from a user's pov.
Somewhere
On Wed, 26 Mar 2014, Jonas Maebe wrote:
On 26/03/14 19:07, Michael Van Canneyt wrote:
On Wed, 26 Mar 2014, Jonas Maebe wrote:
Specifying the directories in a
relative way means that you can easily copy over a debug binary and
all related source code from one system to another (or move thi
On 26/03/14 19:07, Michael Van Canneyt wrote:
On Wed, 26 Mar 2014, Jonas Maebe wrote:
Specifying the directories in a
relative way means that you can easily copy over a debug binary and
all related source code from one system to another (or move things
around) without breaking anything. For t
On Wed, 26 Mar 2014, Michael Van Canneyt wrote:
The problem is easy to reproduce, as Mattias demonstrated.
During debugging, Lazarus consistently opens a file twice (or doesn't find it
at all) when symlinks are used in the path to the project file, because there
is a mismatch
between the r
On Wed, 26 Mar 2014, Jonas Maebe wrote:
On 26/03/14 17:23, Michael Van Canneyt wrote:
At the very least I think that we should be consistent and use the same
filenames in link script and debug info ?
How directories are stored in the debug info is generally defined by the
debug info format
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
Here is a summarize so far:
When the compiler is started in a directory with a symlink, the
directory is resolved and used for error messages and debug info.
All other directories are not resolved.
If you want fpc to use only unresolved paths, you
On 26/03/14 17:23, Michael Van Canneyt wrote:
At the very least I think that we should be consistent and use the same
filenames in link script and debug info ?
How directories are stored in the debug info is generally defined by the
debug info format itself. E.g. the DWARF standard explicitly
On Wed, 26 Mar 2014, Tomas Hajny wrote:
On Wed, March 26, 2014 15:35, Michael Van Canneyt wrote:
On Wed, 26 Mar 2014, Tomas Hajny wrote:
The two should at least match; and you will not be surprised to hear
that
I think the linker file is correct :)
.
.
It makes no sense to use absolute pat
On Wed, March 26, 2014 15:35, Michael Van Canneyt wrote:
> On Wed, 26 Mar 2014, Tomas Hajny wrote:
>>> The two should at least match; and you will not be surprised to hear
>>> that
>>> I think the linker file is correct :)
>> .
>> .
>>
>> It makes no sense to use absolute paths in debug information
Here is a summarize so far:
When the compiler is started in a directory with a symlink, the
directory is resolved and used for error messages and debug info.
All other directories are not resolved.
If you want fpc to use only unresolved paths, you can start fpc in
a directory without sources. But
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 15:33:38 +0100 (CET)
Michael Van Canneyt wrote:
[...]
So ? You just need to check the inode.
Is there a function to list all files pointing to an inode?
Actually, you just need to know if 2 filenames point to the same ino
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 15:19:29 +0100 (CET)
Michael Van Canneyt wrote:
[...]
I tested, and indeed:
# include_directories
.ascii "../../tmp/link\000"
I think this is an error in FPC, because the linker file contains full paths:
INPUT(
/u
On Wed, 26 Mar 2014 15:33:38 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> >> So ? You just need to check the inode.
> >
> > Is there a function to list all files pointing to an inode?
>
> Actually, you just need to know if 2 filenames point to the same inode.
And what 2 files should I check
In our previous episode, Tomas Hajny said:
> > The two should at least match; and you will not be surprised to hear that
> > I think the linker file is correct :)
> .
> .
>
> It makes no sense to use absolute paths in debug information, because it
> would make distribution of units compiled with
On Wed, 26 Mar 2014 15:19:29 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> I tested, and indeed:
>
> # include_directories
> .ascii "../../tmp/link\000"
>
> I think this is an error in FPC, because the linker file contains full paths:
>
> INPUT(
> /usr/local/lib/fpc/2.7.1/units/x86
On Wed, 26 Mar 2014, Tomas Hajny wrote:
The two should at least match; and you will not be surprised to hear that
I think the linker file is correct :)
.
.
It makes no sense to use absolute paths in debug information, because it
would make distribution of units compiled with debug informatio
On Wed, March 26, 2014 15:19, Michael Van Canneyt wrote:
>
>
> On Wed, 26 Mar 2014, Mattias Gaertner wrote:
>
>> On Wed, 26 Mar 2014 13:37:32 +0100 (CET)
>> Michael Van Canneyt wrote:
>>
>>> [...]
>>> But I am arguing that when passing filenames/paths to other tools
>>> (including the compiler), y
On 26/03/2014 14:30, Tomas Hajny wrote:
It makes no sense to use absolute paths in debug information, because it
would make distribution of units compiled with debug information to other
machines impossible (or more precisely - it would be possible to
distribute them, but debugging would not work
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 14:31:19 +0100 (CET)
[...]
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.
Is there a fu
On Wed, 26 Mar 2014 14:31:19 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> > 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 p
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 13:37:32 +0100 (CET)
Michael Van Canneyt wrote:
[...]
But I am arguing that when passing filenames/paths to other tools
(including the compiler), you should always specify full filenames.
The IDE passes all search paths as f
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 12:07:01 +0100 (CET)
Michael Van Canneyt 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
On Wed, 26 Mar 2014 13:37:32 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> But I am arguing that when passing filenames/paths to other tools
> (including the compiler), you should always specify full filenames.
The IDE passes all search paths as full file paths, especially no
'..'. No problem
On Wed, 26 Mar 2014 12:07:01 +0100 (CET)
Michael Van Canneyt 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
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
Michael Van Canneyt 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 w
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 wrote:
On Tue, 25 Mar 2014, Mattias Gaertner wrote:
So, FPC uses a system call to ge
On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
Michael Van Canneyt 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 sa
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 wrote:
>>> On Tue, 25 Mar 2014, Mattias Gaertner wrote:
>>>
>
> So, FPC uses a system call to get the correct (resolved
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
Michael Van Canneyt wrote:
[...]
AFAIK the PWD is the official thing and used by other console tools as
well. For example when I compile a file with gcc in a symlinked
directory it creates debugging info
In our previous episode, Mattias Gaertner said:
> >
> > It's a hack ?
>
> AFAIK the PWD is the official thing and used by other console tools as
> well.
afaik:
1) it is an official thing only of the shell, not the "system".
2) it assumes that any program doesn't change paths inbetween.
(eith
On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> > AFAIK the PWD is the official thing and used by other console tools as
> > well. For example when I compile a file with gcc in a symlinked
> > directory it creates debugging info with the unresolved file name.
>
>
>
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 09:10:09 +0100 (CET)
Michael Van Canneyt 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.
What's wrong wi
On Wed, 26 Mar 2014 10:59:52 +0100
Mattias Gaertner wrote:
>[...]
> But SetCurrentDir does not work. It seems to resolve directories. The
> documentation does not mention this behavior. Is this by design?
The setcwd of C does the same, so I guess it is by design.
It should be documented.
Matti
On Wed, 26 Mar 2014 09:10:09 +0100 (CET)
Michael Van Canneyt 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.
> >
> > What's wrong with this:
> > if GetEnvi
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.
What's wrong with this:
if GetEnvironmentVariable('PWD')<>'' then
SetCurrentDir(GetEnvironmentVariable('PWD'));
It's a hack ?
?
On Tue, 25 Mar 2014 21:07:45 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> > For example a way to tell fpc to use the PWD environment
> > variable?
>
> No.
>
> Because if you do a Chdir('ABC') inside a FPC program,
'a FPC program' sounds as if you are talking about console programs
in genera
On Tue, 25 Mar 2014, Mattias Gaertner wrote:
Hi,
When I start fpc in a directory containing symlinks the compiler uses
the resolved directory, leading to wrong source file names.
For example:
/tmp/orig/project1.pas
/tmp/link -> /tmp/orig
cd /tmp/link
fpc -vb project1.pas
/tmp/orig/project1.
45 matches
Mail list logo
