How to install "libgncmod*.dll" to bin/?

[Christian Stimming]

Am Thursday 20 May 2010 schrieb Geert Janssens:
> On Thursday 20 May 2010, Christian Stimming wrote:
> > Am Thursday 20 May 2010 schrieb Geert Janssens:
> > > On Wednesday 19 May 2010, Tao Wang wrote:
> > > > ./gnucash-bin: error while loading shared libraries: libgnc-qof.so.1:
> > > > cannot open shared object file: No such file or directory.
> > > > 
> > > > So, I have 2 questions:
> > > > 
> > > > 1) should we just change all "pkglib_LT*" to "lib_LT*" in
> > > > Makefile.am? which will build everything to lib/ and in Windows
> > > > installation script, they are automatically copied to bin/
> > > > 2) Not change "pkglib_" prefix, and installed all "libgncmod*.dll" to
> > > > bin/ on Windows only. But how to do that? Modify configure.ac? or
> > > > packaging/win32/install.sh(or dist.sh)?
> > > 
> > > Neither will work because the gnc-module code will explicitly look for
> > > the modules in a lib/gnucash subdirectory.
> > > 
> > > The only clean solution I see is to complete the modularization of
> > > gnucash. The basics are there, but it is not finished.
> > 
> > Actually I propose the opposite direction: The problem is that the
> > architecture was intended to be used in a modular way, but since there
> > 
> >  isn't a real benefit for the developer (except for the optional modules
> >  hbci, ofx, aqbanking), over time the developers blurred the distinction
> >  between shared objects intended as modules and shared objects intended
> >  as shared libraries. The outcome is our current situation: Some shared
> >  modules link into other modules "as if" they were shared libraries, and
> >  won't work if they are not reachable in the library path.
> > 
> > Because of this, I propose to instead remove the modularization of
> > gnucash (except for the abovementioned optional modules) and instead
> > link
> > 
> >  everything just as normal shared libraries, or even link everything
> >  statically into the final gnucash executable.
> > 
> > I've already discussed this here
> > http://wiki.gnucash.org/wiki/Cutecash#No_Plugin_Framework and my
> > 
> >  conclusions are still the same. The modularization into plugin modules
> >  is artificial and doesn't offer any benefit for neither the user nor
> >  the developer. Hence it should be removed.
> > 
> > Regards,
> > 
> > Christian
> 
> Ok, valid points I was not aware of.
> 
> I'm for reducing the number of modules. I do have some reservations still
> though:
> - you mention the optional modules hbci, ofx, aqbanking. I think these
> remain good candidates for just that: modules that are loaded only of the
> user intends to use them. Which implies some form of runtime module
> loading should remain. And the problem of finding the modules at runtime
> as well. But done properly, this issue can be solved by telling gnucash
> where to look for optional modules in the environment config file. I do
> agree that most of the core functionality can do without this added
> complexity.

Yes, these three are examples which might be useful as modules.

> - I'm also hesitant of statically linking it all together. I have probably
> mentioned this before, but I think a clean separation between a gnucash
> library and a gui on top would be useful. This is likely another discussion
> altogether. Reducing the current number of shared libraries to one and one
> executable using it would be nice though.

Yes, sounds good as well - but notice this doesn't need anything similar to 
plugins and loadable modules (with the above exceptions): It would be a 
"normal" application, with perhaps a major lower-level part available as a 
library, but that's about it.

Regards,

Christian