Modules and GnuCash (was: MacIntel trunk build failure)

[Peter McAlpine]

After some investigation it's seems to me that it would be a good idea
to set a clear direction for how GnuCash uses modules.

Here is the problem I see exists now: Upon program initialization the
modules are loaded (as GModule's), but throughout the core code and
the module code GnuCash is directly calling functions that belong to
other modules directly instead of using the interface through the
GModule's. This means that the module libraries and gnucash-bin are
all linking against the modules at compile time (instead of runtime).
One such instances of this "extra" linking is what has caused the
MacIntel build breakage.

Treating the GnuCash modules as both GModule's and [shared] libraries
means that GnuCash gets all the difficulties of a modular design but
very few benefits. In fact the only benefit I see that exists now is
that it's possible to enable/disable
ofx/hbci/log-replay/business-gnome without littering the code with
#ifdef's.

And so I pose this question: is GnuCash to have a modular design or
not? If yes, then the modules need to be ripped apart and made to use
a strict interface. If no, then the GNCModule code should be ripped
out and everything should (go back?) to being treated as a library.

If the answer is "yes, GnuCash is to have a modular design but there
isn't the time for the primary developers to finish its
implementation" then please say so. As it is now I am unable to build
trunk on my primary computer and would consider resolving this problem
to be an interesting exercise.

-Peter

On 2/13/07, Derek Atkins <warlord at mit.edu> wrote:
> I suspect that src/register/register-core and src/register/register-gnome
> should both be turned into LIBRARIES.
>
> I haven't looked at the patch to see what else might want to be a library
> instead of a module.
>
> -derek
>
> Quoting Christian Stimming <stimming at tuhh.de>:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Peter McAlpine schrieb:
> >> While I certainly don't claim to be an expert on the autotools, I
> >> couldn't grasp why the modules' shared libraries should want to
> >> (statically) link against each other, so I removed the offending
> >> libraries from the Makefile.am's and eventually got a clean build. I've
> >> attached the patch to actually get it to built
> >
> > Thanks for the patch. However, if a library's libfoo.la file is
> > mentioned in libbar_LIBADD then this doesn't necessarily mean these
> > libraries are *statically* linked against each other. Instead, it merely
> > means "Dear funky libtool, please make sure this libbar is linked
> > against libfoo, and unfortunatly I have to leave it up to you to decide
> > whether you do this statically or dynamically." If you're on a platform
> > where static linking is switched off anyway (like windows/mingw), then
> > all of these are dynamically linked libraries.
> >
> > In this particular case, removing these linker flags gives plenty of
> > "undefined reference to function xyz" errors on windows. Windows is a
> > particular case here because it doesn't allow any undefined symbol,
> > whereas other unix linkers are fine with some undefined symbols as long
> > as they can be resolved at runtime.
> >
> > Nevertheless these errors are perfectly valid - if the code in libbar
> > calls a function in libfoo, then libbar must be linked against libfoo.
> > I've attached an excerpt of the error messages below.
> >
> > What we *could* do is to reorganize the code split: We could move some
> > functions out of a libgncmod module into a libgnc library and link
> > against that instead of the modules.
> >
> > Regards,
> >
> > Christian
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.2.1 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iQCVAwUBRdHG52XAi+BfhivFAQI7awP/U/a6/OM/Zz+rJVzosNxccgr1YF5mjei9
> > 9PcFioj7PyqEWcUPEF2Tb0pd6VtcD3TXQPPXp3hyDfgVXNt1RiCsMZz6PL40dWIi
> > tuDH/7XuivR1N7Ncs8zPF3mXNsEd6E8/I3/4G+UOLrbECwqYvaPo6n14nCdwY5Uy
> > vq9qdZDGLyc=
> > =hSgx
> > -----END PGP SIGNATURE-----
> >
>
>
>
> --
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord at MIT.EDU                        PGP key available
>
>