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 :
implemented by app/core/core-enums.c and
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