At 17:50 19.09.02 +0200, Sven Neumann wrote:
>Hans Breuer <[EMAIL PROTECTED]> writes:
>> 3) Change the sources to have a clean dependency stack, i.e. no
>>    circular dependencies.
>could you outline which circular dependencies you are talking about so
>that we can discuss if this solution would be feasible ?
As noted in a previous mail (which is 'held until the list moderator 
can review' cause I were subscribed with an older mail address) :

Building DLLs on win32 does require all symbols to be imported by
it to be availble at compile time from anothers (already build)
DLL. A first example :

app/config calls
implemented by app/core/core-enums.c and
implemented elsewhere.
So you need to build app/core before app/config and app/base, while
app/base needs app/config to build and app/core needs app/base ...

Another concrete small example:

app/vectors implements GimpVectors which is derived form GimpItem
implemented in app/core/gimpitem.c. 
app/core/gimpitem.c:gimp_item_name_changed uses the 'dynamic cast'
GIMP_IS_VECTORS(item) which is implemented by

So to build app/core you need app/vectors build first - and vice versa.

Such circular dependencies can be overcome by first building the export
libraries only for both modules and finally use them in a second build 
step to create the DLLs.
But this is difficult to do portable, requires additional code to 
be written _and_ doesn't look like a clean solution. 
Shouldn't a module low in the depency stack depend on modules 
above it ?

The above are only small examples of the build problems with app/core.
There is much more missing to make the appcore.dll. One issue are all
the undo_push_<*> functions currently implemented by app/undo.c. 
There already seems to be a provision to solve this named GimpUndo,
but almost all of app/undo.c requires porting to it.

Another issue which probably would require a special solution are the
modules app/xcf, app/pdb and app/paint which depend on app/core but
get initialized and destroyed by app/core/gimp.c. 
To solve this, one could either move The Gimp Object out of core or 
do some dynamic loading of the subsystems as suggested by the diagram 
attached to my previous mail and now available at:

To sum up: The Gimp sources are already moving in the right direction
[thanks Mitch and Sven there are less unresolved symbols with almost 
any cvs update] but at the moment the task to build all of gimp/app/*
as separate dynamic loadable libraries is too huge for me. Also at 
the moment I don't even see a concrete benefit to do so.
The latter will change to make such things like dynamic loadable
tools possible for non ELF binaries (or at least for win32).


-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert
Gimp-developer mailing list

Reply via email to