Library structure

[Chris Shoemaker]

[ In the process of writing this (rather LONG) email asking for
advice, I think I've discovered an answer, but I'm sending anyway in
case it generates some discussion. ]

Sorry I couldn't think of a better Subject: but I'm having a mental
block on large-scale program structure.

I'll illustrate my problem with a slightly concrete, slightly toy
example.  Right now, gnucash-bin is a PROGRAM,

** From src/bin/Makefile.am **
  bin_PROGRAMS = gnucash-bin

and it depends on the engine library:

  gnucash_bin_LDADD = ...
  ${top_builddir}/src/engine/libgncmod-engine.la \
  ...

Therefore, IIUC, engine has to come before bin in the SUBDIRS of
src/Makefile.am.

Now, what if I have something in gnucash-bin.c that I want to use from
within the engine?  For example, imagine that I needed the
authoritative share_path from inside the engine, and that I could only
construct it in gnucash-bin, from the combination of build-time,
environment and command-line input.

Brainstorming: 

  I could make a src/bin/gnucash-bin.h, and put some global variables
in it.  Then, I think I could include that header from in the engine.
  But, I couldn't declare any functions in the header.  Or if I did,
I'd have to make a separate library out of those functions, because
I'd have to be able to link to those functions without linking to
main().  Anyway, if I made a library, it might possibly depend on the
engine library, and then I'd have two inter-dependent libraries.

Is that a problem?  Only at link-time, right?  Linking gnucash-bin is
not a problem, because it comes last.  But what about linking programs
in src/engine/test?  If I run 'make check' on a completely unmade
tree, wouldn't it try to link programs in src/engine/test before
src/bin/libhypothetical.al was built?

Hmm... < erases white-board >

Maybe I could just move state from gnucash-bin into the engine.  That
works for the engine, but what about when I need the same state from
src/gnome/?  Well, pretty much everything links to the engine, so
that's not a big deal.

It might be nice to have a conceptual distinction between "the gnucash
engine" and "that thing that everything else depends on".  The process
of pulling the main application initialization from guile into C is
sort of creating (as gnucash-bin) a "thing that everything else
depends on" because the guile variables were/are available from pretty
much anywhere and everywhere.  E.g. scm_call(scm_c_eval_string
("gnc:blah-blah"))).  That's why main.scm pulls everything into the
environment.  

But, as a PROGRAM, gnucash-bin is trying to be "the final piece that
links all the libraries together" which is why it should be built
_after_ all the libraries.

< erases white-board again (it's small) >

Maybe the difficulty here is that guile was/is basically being
_everything_ -- the central container for global state and globally
shared functions, _and_ the collection point for all the libraries --
the whole program.  It's at the very bottom of the dependency chain -
everything depends on it, _and_ it's at the very top - it depends on
everything else.

Yeah, I think that's it.  As I extricate application initialization
from guile into C, I can't move both categories into gnucash-bin.c.
That should be just for the over-arching "this collects all the
libraries into one application and depends on everything else, nothing
depends on this" stuff.  Then, there's the "container for global
state, etc., everything (may) depends on this, this depends on
nothing"

Right now, functionally, that second place could be in the engine.
But that doesn't seem right and I think there's benefit in keeping in
out of the engine.  Actually, come to think of it, how about
core-utils?

Ok, I think I've talked myself into this conclusion: Any application
initialization state that gets pulled from guile and used everywhere
else shouldn't be kept in gnucash-bin.  Instead, gnucash-bin can call
into libcore-utils and it can be stored there, where everyone else can
see it without depending on gnucash-bin.


-chris