Created attachment 174369 [details] [review]
Remove backend dependencies from python bindings

This patch removes the incorrect linkage of backends (src/backend/xml and src/backend/dbi) from the python bindings. Backends are automatically loaded from engine_init(), so there shouldn't be any need to even call qof_load_backend_library().

The idea of not loading them via qof_load_backend_library but instead directly link them into the main executable probably comes from me. I consider the plugin architecture of gnucash "not helpful" and instead I propose to move towards a more or less monolithic executable. In particular, the fact of whether the "backend modules" are there or not is already determined at compile time. So what benefit is there in having them as loadable modules, being looked up at runtime? I've tested and verified in my cutecash experiment http://wiki.gnucash.org/wiki/Cutecash#No_Plugin_Framework to link to the backend modules directly, and the python code just copied my code (in gnucash SVN at src/gnc/main.cpp) into their gnucash_core.c code. If you say MacOSX refuses to link to a loadable module directly, I agree this must be changed, but for the use case of the python libraries I would rather turn them into dynamic libraries (maybe as additional compilation result). For the cutecash project, I use the same code that currently results in a loadable module, but compile it as a static library (which is chosen rather easily in cutecash's build system cmake) and let it be initialized through these very functions which you noted in your original post.

Long story short: I think there is benefit in offering the possibility to link to the backend modules as normal dynamic libraries, and hence I would like to keep that possibility. (I additionally question the benefit of using them as loadable modules in gnucash, but that's another discussion which doesn't need to be solved here.)

After Mike E reported that your patch makes the python bindings break, I can also clearly see why: You said the modules should be initialized from engine_init(), but the point is that the python bindings do not want to use that function and instead only use gnc_engine_init_static() !! There is one very good reason for not using engine_init(), because it needs a working Guile environment with a working guile module lookup (i.e. a running guile interpreter). For understandable reasons, the python bindings want to be able to use gnucash without a running guile interpreter environment.

(This is similar to cutecash, where I wanted to get along without running a guile interpreter as well, which is why I added the function gnc_engine_init_static and gnc_module_init_backend_foo in the first place.)

I *thought* getting along without guile means also to not use qof_load_backend_library("dir","module"). I might have been mistaken here, though, and maybe you "just" need to replace gnc_module_init_backend_foo by qof_load_backend_library() in the gnucash_core.i initialization. Maybe this way the dependency that doesn't work on MacOSX is removed and the initialization is still there. But engine_init() for sure relies on guile and we would want to get along without using it here.

I don't see any Guile in that execution path. gnc_engine_init2(), the bit of gnc_engine_int that gnc_engine_init_static leaves out only calls qof_load_backend_library(), which in turn only calls the requisite g_module_foo functions necessary to load the modules and call their init functions.

What's strange is that my svn build on Debian Stretch loads the backend modules anyway. I haven't figured that one out.

Anyway, I asked Mike to try changing gnc_engine_init_static to gnc_engine_init and see what happens.

On the other hand, I don't have any trouble with ripping out all of the module code and just linking the dylibs. All it does is slow down startup and add a bunch of cruft... but we should not do that before 2.4 release, and we should discuss it on the dev list first.

What breaks MacOSX building the python bindings is that on OSX libraries and modules have different signatures. Dlopen will load either, but the dynamic linker will only load libraries.

(In reply to comment #4)
> I don't see any Guile in that execution path. gnc_engine_init2(), the bit of
> gnc_engine_int that gnc_engine_init_static leaves out only calls
> qof_load_backend_library(), which in turn only calls the requisite g_module_foo
> functions necessary to load the modules and call their init functions.
> 
> What's strange is that my svn build on Debian Stretch loads the backend modules
> anyway. I haven't figured that one out.
> 
> Anyway, I asked Mike to try changing gnc_engine_init_static to gnc_engine_init
> and see what happens.

This change works on my system (Fedora12).

(In reply to comment #4)
> I don't see any Guile in that execution path. gnc_engine_init2(), the bit of
> gnc_engine_int that gnc_engine_init_static leaves out only calls
> qof_load_backend_library()

Oh, you are right. Ok, then this is useful only for a different compilation mode in which the backend modules are compiled as (either dynamic or static) libraries instead of modules. This is what I did for cutecash (as observable in the CMakeLists.txt). But for the python bindings the backends are built as loadable modules, and as your observation confirms those can probably be used just fine. Sorry for the noise. :-)

Checked in in r19812, along with reordering the args to session.__init__(). (I meant that to be separate commits, but svn got away from me. Oh well.)

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=634712. Please update any external references or bookmarks.