[fpc-pascal] Cross platform question about lpi file content

[Sven Barth]

Am 27.09.2020 um 22:07 schrieb Bo Berglund via fpc-pascal:
> On Sun, 27 Sep 2020 19:44:36 +0200, Sven Barth via fpc-pascal
> <fpc-pascal at lists.freepascal.org> wrote:
>
>>> I am not using wsmenus...
>>>
>> Yes, you are, even if it is indirectly. Otherwise the compiler or linker
>> wouldn't complain about it.
>>
> It would be very good if the linker could be told to show a message
> saying from where the call to the missing identifiers came.
>
> Now it just prints a long list of undefined references to WSxxx
> identifiers, without showing where the call that brought up wsmenus.pp
> came from. Like:
> wsmenus.pp(263,1) Error: undefined reference to `WSRegisterPopupMenu'
>
> Why is it there?
>
> As it is now I have inspected all project units to see if there is any
> un-needed uses clause that might bring in GUI components.

The linker *does* point you as good as possible at the location of the 
call, namely unit wsmenus.pp at line 263 which does contain a call to 
"WSRegisterPopupMenu". It *can't* do any better, because it does not 
know from where the surrounding "RegisterPopupMenu" is called (okay, not 
quite true: the linker knows *all* references to "RegisterPopupMenu", 
but do you really want to be flooded by a list of functions that in turn 
might need a list of functions each that they're called from and so on?)

Though admittably this specific case is even more complex, cause 
WSRegisterPopupMenu is declared as "external" and the "public" symbol is 
provided elsewhere, thus you won't get the compile error that a unit is 
missing.

> I have used a conditional "GUI_MODE" to enable/block all uses of GUI
> calls like Message boxes and the like. Also to replace
> Application.ProcessMessages with Sleep() so I can condition away Forms
> in the uses clause on the GUI_MODE identifier (which is not set).
Your own units are not the only ones in your project. Indy is notorious 
for requiring GUI code if you pick the wrong units.
> In Delphi I believe it was possible to use for example Forms in a
> command line application so that Application.ProcessMessages could be
> called. But it seems not so with FPC/Lazarus.

Lazarus is not Delphi. In Delphi this worked, because on Windows the GUI 
libraries are always available and Windows doesn't care if you use UI 
code in a "console" binary. On other systems (especially Linux and BSD) 
this might not be the case however, thus linking against e.g. GTK or Qt 
(which the LCL does depending on the widgetset) would just lead to 
"library not found" errors at the point you'd start the application. And 
trust me, on a headless system you don't *want* to install a complete 
X11 or Wayland stack just to get your program working. That is why the 
NOGUI widgetset was introduced. To give units that require GUI access 
(like some parts of Indy) the chance to work in CLI applications. Though 
of course it's even better to get rid of such dependencies, but Indy is 
big and thus one probably needs to adjust/rewrite quite some of their 
units to make sure that there are no unnecessary GUI dependencies...

Regards,
Sven