At 17:50 19.09.02 +0200, Sven Neumann wrote: >Hi, > >Hans Breuer <hans@xxxxxxxxxx> 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 gimp_thumbnail_size_get_type() gimp_preview_size_get_type() gimp_image_base_type_get_type() gimp_cursor_mode_get_type() gimp_help_browser_type_get_type() implemented by app/core/core-enums.c and gimp_unit_get_identifier() 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 app/vectors/gimpvectors.c:gimp_vectors_get_type(). 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: http://hans.breuer.org/gimp/the-gimp-modular.htm 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). Regards, Hans -------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert
