My question was OS independent. However, thanks for the reply.
Is there any way to get the full path name?How is that meant?
Don't beat me if this is wrong... For example, I could imagine that when a project is structured in subfolders you might not get the subfolder of the file...
As know, {$include %file%} is expanded by compiler with the name of current source file. As far as I understand, the filename is without the path. Is there any way to get the full path name? Thank you.
My question was OS independent. However, thanks for the reply.
Your question is NOT OS-independent since it depends on the shell/environment variables made available, and is NOT version-independent since the $I expansions might change.
I think that the IDE changes path to the directory with the project file. So, you could try this:Don't beat me if this is wrong... For example, I could imagine that when a project is structured in subfolders you might not get the subfolder of the file...
program project2; uses SysUtils; begin writeln(IncludeTrailingPathDelimiter(GetCurrentDir) + {$include %file%}); readln; end.
[…] Is there any way to get the full path name? […]No, not without external help. With bash(1) or zsh(1) you could do something like
No, there is no way.
No, there is no way.I could be wrong but, if the program is compiled with debugging symbols, doesn't the full filename end up somewhere in there ?
You could do something likemaybe.
program project1; {$macro ON} {$define mypath:= extractfilepath(paramstr(0))+{$include %file%}} uses sysutils; begin writeln(mypath); readln; end.
No, there is no way.
With respect, I express qualified disagreement: I strongly suspect I could do it on unix provided that the build was handled by Lazarus (a carefully-tailored echo|tr in "Execute before" creating a string in a .inc file).
There is no built-in way (except maybe using debug information as 440bx hinted at, but that means parsing that whole stuff and including it in the first place which might not be desired).
What about a resource file with the file's (birthplace) written in, for member GetMem, who reckons this is what is required.
ExeName=C:\FPC_SourceName\SourceName.exeThe code to generate the above result is :
$main SourceFile=C:\FPC_SourceName\SourceName.pas
DoProjUnit C:\FPC_SourceName\SubDir\projunit.pas
DoProjUnit C:\FPC_SourceName\SubDir\SubSubDir\projuniti.INC
Win x86_64 {$I %sourcefile%}, compiler patch to add %sourcefile%.
When run with patch applied, the zipped project with 3 units, will output :QuoteExeName=C:\FPC_SourceName\SourceName.exeThe code to generate the above result is :
$main SourceFile=C:\FPC_SourceName\SourceName.pas
DoProjUnit C:\FPC_SourceName\SubDir\projunit.pas
DoProjUnit C:\FPC_SourceName\SubDir\SubSubDir\projuniti.INC
WriteLn({$I %CURRENTROUTINE%}, ' SourceFile=', {$I %sourcefile%});
To work, you need to apply the SourceFIle.patch to FPC 3.2.2 and rebuild the FPC compiler.
... worth having.I think that recompiling application mentionned in
MarkMLl
Re: ??? How is this possible ???with the {$I %sourcefile%} in the units in correct places might show exactly what units are included and whether it is what it is expected.
Or one of the path macros, like $(ProjOutDir). Etc.