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

[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.
- 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.

Geert