[PATCH] [REVIEW] python bindings and lost business data

[Christian Stimming]

Am Thursday 10 June 2010 schrieb Mark Jenkins:
> This, and the linking decisions in Makefile.am are the most critical
> elements of the python bindings. (...)
> 
> With this patch, this init section in gnucash_core.i becomes:
> g_type_init();
> scm_init_guile();
> gnc_module_load("gnucash/engine", 0);
> gnc_module_load("gnucash/business-core", 0);
> gnc_module_load("gnucash/business-core-xml", 0);
> gnc_module_load("gnucash/business-core-sql", 0);
> 
> It strikes me as over kill that scheme is needed for this, but its my
> understanding that the gnc_module stuff depends on that.

When I wrote cutecash, this stroke me just as well. I decided it can't be 
technically required to have scheme in all of this. That's why I came up with 
the other pure C solution you have found in cutecash's src/gnc/main.cpp:

> qof_log_init();
> qof_init();
> gnc_module_system_init();
> char * no_args[1] = { NULL };
> gnc_engine_init_static(0, no_args);
> 
> gnc_module_init_backend_xml();
> gnc_module_init_backend_dbi();
> gnc_module_init_business_core_init();
> gnc_module_init_business_core_xml_init();
> 
> void gnc_address_sql_initialize( void );
> void gnc_billterm_sql_initialize( void );

but the long list with foo_sql_initialize I have missed so far. This should 
immediately be moved into a function which is reachable from the outside of 
the gncmod_business_backend_sql, similar to what I've done in r18841 with the 
business-backend-xml.

It is my strong opinion this whole module implementation is completely 
overdone and unnecessary for the gnucash core part. Instead, the business 
objects should be moved into the engine, and most of what currently is a 
loadable module should simply be statically linked into one single libgnc-
engine shared library, which is then used by the final executable.

But then again, with the python wrappers you don't want or need to change the 
way gnucash works right now, but merely have to adapt to it...

> That also seemed to work, but the additional linking I had to throw to
> _gnucash_core_c_la_LIBADD (from
> src/optional/python-bindings/Makefile.am) in against
> ${top_builddir}/src/backend/xml/libgncmod-backend-xml.la
> ${top_builddir}/src/business/business-core/xml/libgncmod-business-backend-x
> ml.la
> 
> ${top_builddir}/src/backend/dbi/libgncmod-backend-dbi.la
> and
> ${top_builddir}/src/business/business-core/sql/libgncmod-business-backend-s
> ql.la
> 
> resulted in a warning that linking against those wasn't portable.

The linking is of course required because with your C code you are using 
functions from those shared objects. The warning is potentially true because 
currently all the libgnc*mod* libraries are marked as being loadable modules 
instead of "normal" shared libraries. However, I still think we should change 
them back into normal shared libraries and/or integrate them statically into 
the existing libgnc-engine shared library, which would then solve any 
remaining linking portability issues.

Regards,

Christian