How to set HostApplication with a relative path or something similar?

[EMBarbosa]

We have a  multiplataform lib (.dll/.so) that many devs are working on.

The code is on SVN/Git, so any dev checkout it in different folders/drivers.

But when we set the https://wiki.lazarus.freepascal.org/IDE_Window:_Run_parameters#Host_Application, Lazarus can't find the host application. The way I see, it doesn't respect macros or relative path.

Is it true? How we can configure the lib in a way it would work to any dev?

[Martin_fr]

This is probably something that should be improved. Maybe add a bug-or-feature-request. So it will be known.

[EMBarbosa]

This is probably something that should be improved. Maybe add a bug-or-feature-request. So it will be known.

Thank you Martin.

I didn't looked for it before, but I found this one:

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/32331

I don't know what the "Advice" in the title of this issue means, but as I see, it is already reported. Right?

[Martin_fr]

This is probably something that should be improved. Maybe add a bug-or-feature-request. So it will be known.

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/32331

I don't know what the "Advice" in the title of this issue means, but as I see, it is already reported. Right?

Indeed, already there.

I have not tested, but it is possible that the "patch" https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/32331#note_638205833 still works.
It may not be the final solution, but it may at least give you some workaround.

[EMBarbosa]

I have not tested, but it is possible that the "patch" https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/32331#note_638205833 still works.
It may not be the final solution, but it may at least give you some workaround.

Thank you. I will try this patch.

But another thing that I tried to test is the option to "launching application".

When we check that option, then the "host application" should not be used at all, right? But the IDE checks if the file exists or if the host application parameter is empty.

If the IDE used only the cmd line provided below, then it everything would work, I think.

[EMBarbosa]

I commented this in the issue. But as I'm not familiar with the the IDE code, I'm not sure if it is right.

[EMBarbosa]

I have not tested, but it is possible that the "patch" https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/32331#note_638205833 still works.
It may not be the final solution, but it may at least give you some workaround.

Hi Martin. It doesn't work anymore. Now there is a code in TMainIDE.DoInitProjectRun that validate if the application exists using FileExists.
line 7258 of Main.pp:

Code: Pascal  [Select][+][-]

1.   // Check project build
2.   ProgramFilename := MainBuildBoss.GetProjectTargetFilename(Project1);
3.   if ConsoleVerbosity>0 then
4.     DebugLn(['Hint: (lazarus) [TMainIDE.DoInitProjectRun] ProgramFilename=',ProgramFilename]);
5.   if ((DebugClass = nil) or DebugClass.RequiresLocalExecutable)
6.      and not FileExistsUTF8(ProgramFilename)
7.   then begin
8.     debugln(['Info: (lazarus) [TMainIDE.DoInitProjectRun] File TargetFile found: "',ProgramFilename,'"']);
9.     IDEMessageDialog(lisFileNotFound,
10.       Format(lisNoProgramFileSFound, [ProgramFilename]),
11.       mtError,[mbCancel]);
12.     Exit;
13.   end;  

[Martin_fr]

Haven't looked at any related code for some time...

The file that the debugger will run, is set in
unit DebugManager

Code: Pascal  [Select][+][-]

1. function TDebugManager.InitDebugger(AFlags: TDbgInitFlags): Boolean;
2. ...
3.   if not(difInitForAttach in AFlags) then begin
4. ...
5.   else
6.     GetLaunchPathAndExe(LaunchingCmdLine, LaunchingApplication, LaunchingParams, False);
7. ...
8.       if FDebugger <> nil
9.       then FDebugger.FileName := LaunchingApplication;

But I haven't tracked where the values from the settings are retrieved.

Also, all of this code has been written for gdb (and much of it in the old days, for older gdb, and for really old Linux terminals).

Not sure how much of it was updated over time. And most of it want have been tested with FpDebug.

There are several issues debugging libraries, when it comes to setting breakpoints (including those internally set by the IDE to catch exceptions). IIRC There is a bit about it somewhere on the wiki.... It may work with current versions of gdb.


Currently my time goes to work on the debugger frontend and fpdebug for general debugging.
Depending what comes up, some fixes and work outside the debugger.
And then hopefully improve debugging of libraries. (fixing the breakpoint issue, and at that time - if not forgotten - look at the hosting app)

[EMBarbosa]

Haven't looked at any related code for some time...
But I haven't tracked where the values from the settings are retrieved.

I've debugged the IDE. And this code is never executed if the settings has a relative path, "macro" or "environment var". The error message I've mentioned in original post is launched by this code in Main.pp:

Code: Pascal  [Select][+][-]

1.      
2.       // Check project build
3.       ProgramFilename := MainBuildBoss.GetProjectTargetFilename(Project1);
4. ...
5.       if ((DebugClass = nil) or DebugClass.RequiresLocalExecutable)
6.          and not FileExistsUTF8(ProgramFilename) // <---- HERE! This code should not validate the EXE before parse relatives paths/macros/envvar... IMHO
7.       then begin
8.         debugln(['Info: (lazarus) [TMainIDE.DoInitProjectRun] File TargetFile found: "',ProgramFilename,'"']);
9.         IDEMessageDialog(lisFileNotFound,
10.           Format(lisNoProgramFileSFound, [ProgramFilename]),
11.           mtError,[mbCancel]);
12.         Exit;
13.       end;
14.  

The file that the debugger will run, is set in
unit DebugManager

Yes... but the IDE doesn't execute this code. The execution is halted in Main.pp as said before.

I want to help, but I'm not familiar with the IDE code and I'm struggling in find any direction. If there is anything I could do, please guide me.

Thanks you for your time 'til now.

[EMBarbosa]

ok... I did investigate a little more... and apparently found a patch for solve this.

The file checked by the IDE is mounted in MainBuildBoss.GetProjectTargetFilename().
There, the code checks for macros, but only some IDE functions macros (the ones listed in https://wiki.freepascal.org/IDE_Macros_in_paths_and_filenames#Filename_Parts except MakeEXE and MakeLib).

This is the actual code:

Code: Pascal  [Select][+][-]

1. function TBuildManager.GetProjectTargetFilename(aProject: TProject): string;
2. var
3.   AMode: TRunParamsOptionsMode;
4. begin
5.   Result:='';
6.   if aProject=nil then exit;
7.   AMode := aProject.RunParameterOptions.GetActiveMode;
8.   if AMode<>nil then
9.     Result:=AMode.HostApplicationFilename;
10.   GlobalMacroList.SubstituteStr(Result);
11.   if (Result='') and (aProject.MainUnitID>=0) then begin
12.     Result := aProject.CompilerOptions.CreateTargetFilename;
13.   end;
14. end;

So I changed the code to:

Code: Pascal  [Select][+][-]

1. function TBuildManager.GetProjectTargetFilename(aProject: TProject): string;
2. var
3.   AMode: TRunParamsOptionsMode;
4.   PathTarget: string;
5. begin
6.   Result:='';
7.   if aProject=nil then exit;
8.   AMode := aProject.RunParameterOptions.GetActiveMode;
9.   if AMode<>nil then
10.     Result:=AMode.HostApplicationFilename;
11.   GlobalMacroList.SubstituteStr(Result);
12.   if (Result <> '') and (not FilenameIsAbsolute(Result)) then
13.   begin
14.     //alow relatives paths in HostApplicationFilename
15.     PathTarget := ExtractFilePath(aProject.CompilerOptions.CreateTargetFilename);
16.     Result := CreateAbsolutePath(Result, PathTarget);
17.   end;
18.   if (Result='') and (aProject.MainUnitID>=0) then begin
19.     Result := aProject.CompilerOptions.CreateTargetFilename;
20.   end;
21. end;

Got a "works in my machine" seal of approval.


I'm not sure it should be implemented this way, as it raise the following questions:
1) The path should be relative to what? The project Dir or the target file dir?
2) Shouldn't other macros, "env var", etc... be checked too?
3)??

[EMBarbosa]

I forgot the patch file...

[Martin_fr]

I'm not sure it should be implemented this way, as it raise the following questions:
1) The path should be relative to what? The project Dir or the target file dir?
2) Shouldn't other macros, "env var", etc... be checked too?
3)??

1)
The target file (if set in the "path" options page) is relative to the project.
So I would say relative to the project directory.

That also goes well with the idea that the host app is in another project. That is likelier easier to find from the current project dir, than from somewhere within (where the exe happens to have ended up)

However see my notes on the gitlab issue
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/32331#note_1223207591


2)

I just tested (Lazarus 2.3 - Win10), this works as host application:
$(ProjSrcPath)\..\foo\project1.exe

Search the IDE for "GlobalMacroList" and you should get all the macros that are added.

[Martin_fr]

1)
The target file (if set in the "path" options page) is relative to the project.
So I would say relative to the project directory.

That also goes well with the idea that the host app is in another project. That is likelier easier to find from the current project dir, than from somewhere within (where the exe happens to have ended up)

However see my notes on the gitlab issue
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/32331#note_1223207591

2nd though => relative to the "working dir".

Might need an extension in the IDE, to query if the debugger already deals with it.

[Martin_fr]

If I am not mistaken (and it's late for me, so ....)

If anything is currently handled (eg by gdb) then it likely does
1) an exe without any path: current dir / $PATH
2) an exe with a relative path (i.e. having any / (on Win \ ) in it: relative to current dir.

So if we add to the "not FilenameIsAbsolute" that also "pos(PathSeparotor, exe) > 0" then it should be save to rebase onto working dir.

Let me sleep on that....
(unless it affects the exe name in ARGV[0])

Sorry, I am picky.
But experience shows that other people always relay on those things that I don't have in mind...

[EMBarbosa]

Sorry, I am picky.
But experience shows that other people always relay on those things that I don't have in mind...

Hi Martin, you don't need to apologize. Someone needs to protect the code, and in this case I'm the one breaking things,

Seriously now, I'm a developer of others open source projects, so I really understand this.

I'm just busy with another problem right now. So I will try to back to this later today.
TY