[gcompris-devel] window port progress

[Olivier Samyn]

Christof Petig wrote:

> Bruno Coudoin schrieb:
>
>> I have been able to compile gcompris on windows using mingw but I am
>> currently blocked by the plugins.
>> What happens is that I cannot create shared libs for the plugins because
>> it tell me the gcompris core entry points are missing.
>> It seems that I have 2 options:
>> - create a lib of gcompris core and share link both gcompris and the
>> plugins with it (uncertainty path).
>> - create a static version of gcompris were all plugins are staticaly
>> linked with gcompris core (code change but will work for sure)
>
>
> to me #1 looks like the favorite way to go. #2 really makes gcompris' > good plugin architecture ashamed.
>
> Did you investigate a third road: Use a dynamic loader which can > postpone symbol resolution to runtime on windows (this probably means > no .dll but .o files). IIRC libtool (libltdl, GNU dld) has such a > tool. #1 is the most native solution on Win32 though.


I already done a windows port of a pluggable application, like gcompris. 
And the best way for me is to have a library to link with.
So, separate some gcompris core functions from the gcompris core...

For a quick review of what are the necessary functions/structures to export, just take a look at the api offered by the python pluggin. It tries to export all gcompris plugins necessary functions :)

This will also help us separating the plugins tree from the main one. (and help to resolve the problem José mentionned possible plugins location in something like ~/.gcompris)

Bruno, I you want, I will try to take a look at this during the next week...

Olivier.