[lazarus] LCL circles

[Mattias Gaertner]

On Fri, 25 Oct 2002 14:32:53 +0200
"Marc Weustink" <marc.weustink at cuperus.nl> wrote:

> + From: Mattias Gaertner [mailto:nc-gaertnma at netcologne.de]
> 
> [SNIP]
> 
> + The trick circle Interfaces.pp <-> LCL:
> + I guess, only the developers know about this one and its purpose, so
> + here is the story:
> +
> + The LCL is the basic component set. The widget interfaces (gtk,
> gnome,+ win32) lie above the LCL and use directly the LCL units. And
> the LCL+ communicates to the interfaces via the abstract
> TInterfaceBase object.+ This object is created in interfaces.pp. When
> compiling the LCL the+ interfaces.pp of the abstract directory is
> used.+ When compiling one of the real interfaces (e.g. gtk) the
> abstract+ interfaces.ppu in the lcl/units directory is deleted and a
> gtk-specific+ interfaces.ppu is created in lcl/units/gtk.
> + When you compile an LCL application the compiler finds 'forms' in
> the+ uses section and loads lcl/units/forms.ppu, which uses
> 'interfaces'. But+ this time the compiler uses the interface specific
> + lcl/units/gtk/interfaces.ppu, which would normally be impossible,
> + because this is a forbidden pascal unit circle:  forms -> interfaces
> ->+ gtkint -> forms
> 
> It is not realy a forbindden circle, more an unwanted circle.
> 
> Forms reffered to iterfaces in its implementation section.

You are right. Sorry.
But fact is, that fpc is not able to compile the LCL and the
gtk-interfaces in one go.
Just copy all units into one directory and fpc will show you what it
things about all this loops:

[...]
Compiling interfaces.pp
Compiling interfacebase.pp
interfaces.pp(34,21) Error: Identifier not found TINTERFACEBASE
interfaces.pp(34,35) Error: Error in type definition


> + The advantage of this trick is:
> + - In the program source (.lpr) you don't need to add 'interfaces'.
> +
> + The disadvantages of this trick are:
> + - The interfaces.pp must be compiled several times to make sure,
> +   that the compiler syncs all units. This is the reason, why you
> +   can't add lcl and lcl/interfaces/gtk to the unitpath.
> 
> For normal apps, this shouldn't be a problem.

Right. 
The problem is of course, that _if_ someone does it he got strange
errors. Therefore we had to add several FAQs to make sure that no one
run into this trap. And also we added Template paths to the IDE so that
newbies don't try.

OTOH adding 'interfaces' to a file, that is normally auto created by the
IDE is also not a problem.


> + - The compilation is somewhat tricky and so the Makefiles are
> +   more complicated.
> 
> True
> 
> + - Forcing the compiler to create a forbidden pascal circle is IMHO
> +   a bad example for coding.
> 
> See above.
> 
> + I hope this was not too negative. I don't want to offend someone,
> + because of coding style. This is open source, so everyone can write
> if+ he/she thinks that something can be done better.
> 
> I don't feel offended :-)
> 
> The reason for the construction as it is now is pure historical. While
> the project grew,  more and more knowledge of the LCL was needed in
> the interface {*}. Since we were developing only for a GTK set, this
> could be compiled in one go (interface and LCL).
> Problem introduced here is that one needs a compiled LCL for every
> widgedset. So if one wants to make an app for different widgetsets,
> one has to have all the different binary LCL's. With the current
> solution one has one LCL (and onle different interface units)

I think, your statement could be misinterpreted by newbies as if we
_must_ use the current construction to separate the LCL from the
interfaces. This is not the case. We can compile the LCL without
interfaces.pp and use only interfacebase.pp.


> {*} And still IMO when the interface has more common functions and/or
> events the interface doesn't have to know anything about the LCL. And
> there would be no circle.

Why that? The LCL has its abstract interface. So, why should the
interface not ly above the LCL and use it?


Mattias