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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
