[fpc-pascal] fpc in symlinked directory

[Mattias Gaertner]

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.
> >
> > What's wrong with this:
> >  if GetEnvironmentVariable('PWD')<>'' then
> >    SetCurrentDir(GetEnvironmentVariable('PWD'));
> 
> It's a hack ?

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.

But SetCurrentDir does not work. It seems to resolve directories. The
documentation does not mention this behavior. Is this by design?


> > ?
> >
> >> So, the best Lazarus can do is resolve all directories before calling the compiler.
> >
> > If you mean with "resolve" to convert relative paths to absolute paths:
> > That is not sufficient.
> 
> Yes it is. 
> But you must do it correctly for ALL paths, and take care to use absolute paths only.
> Relative paths and symlinks do not work.
> > For example when the program uses a unit in the same directory, the
> > compiler uses its current directory.
> 
> What does that mean ? Can you give a command-line example ? 

I used this one:
cd /tmp/link
/usr/bin/fpc -g -gl -vb -Fi/tmp/link -Fu/tmp/link/
-FU/tmp/link/ /tmp/link/project1.lpr

unit1.o:
<33>   DW_AT_comp_dir    : /tmp/orig/
 

> (sources and all)

Pretty straightforward:

-----------------------------
program project1;

uses sysutils, Unit1;

begin
  DoSomething('');
end.
------------------------------
unit Unit1;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils;

procedure DoSomething(s: string);

implementation

procedure DoSomething(s: string);
begin
  writeln('DoSomething ',s);
end;

end.
--------------------------------

 
> >> Since you brought it up:
> >> IMHO Lazarus must do this resolving anyhow, because now Lazarus does not work at all with symlinks, e.g. to find filenames and resolve packages. Regardless of what the compiler does.
> >>
> >> I submitted bugreports on the list about this in the past.
> >
> > I remember some problems. Formerly the IDE resolved symlinks, which
> > was wrong. This was fixed.
> 
> That depends on what you call 'fixed' :)
> 
> I use a lot of symlinks. To this day, the IDE cannot handle them correctly.
> 
> I must always take great care not to select a project/package using a symlink,
> but always must use the 'correct' resolved path.
> 
> The problem is the use of relative paths to indicate units of dependent packages. 
> I have asked in the past to specify paths to packages as absolute 
> paths, never relative: 
> if you use relative paths, things will get messed up when using symlinks.

It works here. Please create a bug report.

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.
Only when writing a file the IDE needs to check for symlinks.

 
> And it has nothing to do with the compiler, the compiler isn't called
> when loading a package or a project, or specifying paths to packages.

No, but with the current state of the compiler, symlinks are not
supported.

Mattias