GNOME Bugzilla – Bug 419063
libgnomedb library merge
Last modified: 2007-03-22 20:10:50 UTC
libgnomedb-3 and libgnomedb_handlers-3 are interdependent, which raises all sorts of issues for both Win32 (req. bootstrapping) and Linux (with -Wl,--as-needed or -Wl,-z,defs). The proposed solution was to merge these two libraries into one; see bug 349548 for the same story with libgda. (While I'm at it, my patch will rename all libraries to -3.0 instead of -3 for consistency with libgda.) libgnomedb/data-entries/plugins/ would have to be moved up one (or two) levels so that libgnomedb-3.0.la will be compiled before libgnomedb_entry_builtin_plugins.la which depends on it. IOW: - first make libgnomedb/data-entries/libgnomedb_handlers-3.0.la as a convenience lib; - then make libgnomedb/libgnomedb-3.0.la as a shared lib, including the former; - only then make libgnomedb/plugins/libgnomedb_entry_builtin_plugins.la. Hopefully this is agreeable. But the problem I've found with that is libgnomedb/data-entries/*.c #include <libgnomedb/marshal.h>, which isn't made yet because data-entries is done first. So I'm a bit stuck. Ideas?
I guess that the directory moves will be difficult via a patch. I can do this if you like, and you can check it afterwards.
Right, and the Makefile.am will need a patch before the move. Everything else should be ready, except that we need to figure out how to deal with the marshaler rules.
Are any of the following options acceptable and/or preferable: a) Move libgnomedb/data-entries/*.{c,h} into libgnomedb/ (could be as a separate convenience lib); b) Make libgnomedb/data-entries/*.{c,h} not depend on the marshal code; c) Move marshal.list and the marshaling into a new libgnomedb/marshal/, append marshal to SUBDIRS, and change all includes to #include "marshal/marshal.h" (or #include "marshal.h" and add -I$(top_srcdir)/libgnomedb/marshal to INCLUDES); d) Duplicate marshal.list and marshal.h generation in libgnomedb/data-entries/, and change #include "libgnomedb/marshal.h" to #include "marshal.h" e) Something else?
> But the problem I've found with that is libgnomedb/data-entries/*.c #include > <libgnomedb/marshal.h>, which isn't made yet because data-entries is done > first. So I'm a bit stuck. Ideas? That's probably just to avoid creating similar marshallers again, just for the sub-directory. But we can create our own marshallers just for data-entries. So, yes d) would work. Note that I had thought that these separate libraries were being installed as separate shared libraries, and that's why I was most concerned. That's not the case - these are just non-installed libraries in the sub-directories for use during the building of the actual shared libraries which are installed.
Created attachment 84942 [details] [review] libgnomedb lib merge patch FIRST, apply this patch; THEN mv libgnomedb/data-entries/plugins libgnomedb/plugins (for testing, a symlink will suffice) ./autogen.sh && make Note that there have been other file additions and removals, so be careful with SVN. * Makefile.am: * configure.in: * control-center/Makefile.am: * doc/C/Makefile.am: * extra/Makefile.am: * extra/demos/Makefile.am: * glade/Makefile.am: * glade3/Makefile.am: * libgnomedb-3.0.pc.in: * libgnomedb-extra-3.0.pc.in: * libgnomedb-extra/Makefile.am: * libgnomedb-graph-3.0.pc.in: * libgnomedb-graph/Makefile.am: * libgnomedb/Makefile.am: * libgnomedb/data-entries/Makefile.am: * libgnomedb/data-entries/gnome-db-data-cell-renderer-boolean.c: * libgnomedb/data-entries/gnome-db-data-cell-renderer-combo.c: * libgnomedb/data-entries/gnome-db-data-cell-renderer-info.c: * libgnomedb/data-entries/gnome-db-data-cell-renderer-textual.c: * libgnomedb/data-entries/marshal.list: * libgnomedb/data-entries/plugins/Makefile.am: * providers/evolution/Makefile.am: * testing/Makefile.am: Rename all libraries from -3 to -3.0. Change libgnomedb_handlers into a convenience lib and merge it into libgnomedb. Fixes compilation with -Wl,--as-needed or -Wl,-z,defs and obsoletes the Win32 bootstrapping; patch in bug 419063. * libgnomedb/data-entries/plugins/*: Moved to libgnomedb/plugins to accomodate the merge. * win32/Makefile.am: * win32/dummy.la: * win32/libgnomedb_handlers-3.def: Removed.
Unfortunately, libgnomedb/plugins then needs libgnomedb/marshal.h, which is not built when libgnomedb/plugins is being built.
Oops. In libgnomedb/Makefile.am, after patching, change: -SUBDIRS = data-entries plugins +SUBDIRS = data-entries . plugins
Ping? This is blocking the API freeze.
I seem to have managed to check this in yesterday, but I had various svn errors, and I'm actually surprised that the checkin succeeded. Could you take a look and check that it's OK?
libgnomedb/data-entries was empty in svn. I've fixed that now, using the content from your patch. By the way, I hope that the various marshal.list files still contain only the marshallers that those sub-libraries actually need. It builds for me at least.
> By the way, I hope that the various marshal.list files still contain only the > marshallers that those sub-libraries actually need. I just did cp libgnomedb/marshal.list libgnomedb/data-entries/marshal.list, so I can't say for sure. Keep in mind that in libgnomedb/data-entries/ only marshal.h is made; marshal.c is of course only made once in libgnomedb/ as it was before.
Created attachment 85129 [details] [review] GNOME_DB_EXPLICIT_TRANSLATION_DOMAIN lib rename I missed this one during the library rename: * configure.in: Rename GNOME_DB_EXPLICIT_TRANSLATION_DOMAIN library name too. Otherwise, looks good. Let's start the countdown to 3.0.
Applied. Thanks.