[lazarus] Multiplatform

[Sebastian Günther]

Jeff Wormsley wrote:

[...]
> Let me know if have completely missed the boat on what you are trying to do...


Basically, the main goal is to have this implemented without adding any
overhead to application developers, and it should be as efficient as
possible.
If you want to do something dynamically, you will have to use ELF
libraries or DLL's, of course.
Now there are two possibilities:
a) you have a toolkit which 'only' supports source-code compatiblity
(and one lib file per target), or
b) you have a set of lib files which are binary compatible, and you have
some kind of mechanism which allows you to decide at run time which lib
to use.

a) is quite simple, this is what all libraries are doing, and which is a
little bit difficult to handle in Pascal: you have an interface unit,
the implementation part consists of 'external' directives; and the
implementation tries to implement the interfaces you have declared... in
KCL for example this wouldn't be too hard to add, as it uses C-like
header files (includes), which could be shared between both parts.
Currently I'm playing around with this approach, and I'm not sure if it
is really possible to have a totally external class, which can be used
without noticing any difference from a programmers point of view. But
I'm quite optimistic that this will be possible, as VCL supports this,
too, for a long time.

b) would be _much_ more difficult to implement, as you would have to
provide some kind of indirection layer, i.e. a unit or library which you
can link against and which dyn.loads an appropiate implementation
library.
I'm proposing to do the following:
You start with approach a) and add an additional library as indirection
layer. All those libraries share the same interface, so you are free to
link your applications against a specific library.
I'll give an example now, please forgive me to choose KCL again in the
Lazarus mailing list: In the near future, there may be two libs called
'libkcl_gtk.so' and libkcl_qt2.so' (perhaps there will be a 'libkcl.so'
with all platform-independent stuff, I don't know yet). In a) you would
have to choose if you link to libkcl_gtk or libkcl_qt. Now we're
introducing this indirection layer called 'libkcl_dyn.so'. If you link
to this library, it will decide which target to choose automatically,
you won't have to change the code of your application for that. In KCL,
- all methods (except constructors) have to be virtual, as virtual
methods don't generate any relocation information
- there should be as few global procs/functions as possible; no global
vars

As speed it not really an issue here, it would be no problem to use only
virtual methods, which are suboptimal in most cases.
This approach has a big advantage: It can be added sometimes later
without requiring changes to the 'real' implementations. Basically, it
allows three different linking modes:
1. static linking: One target library is included in the application's
binary file
2. semi-dynamic linking: Application is linked against a specific target
library
3. real dynamic linking: Application is linked against
libkcl_dyn.so/kcl_dyn.dll, the same binary will run with different
target libraries.
Application which use the internally used handles probably won't run
using (3), of course.

I can only speak for KCL here: Its current state is (1), (2) is planned
to be added very soon, and (3) will be added as soon as there are more
than 1 targets available on a single platform. This will be the case
when it is possible for Win32 KCL applications to use GTK or the native
win32 implementation (kcl_gtk.dll and kcl_w32.dll).

At least it is possible to handle Win32 DLLs and Linux ELF libs the same
way, as the dynamic loading APIs are very similar. (we only need 3
functions: Load library, get address of procedure, and unload library).


- Sebastian