code in cvs is broken

[Derek Atkins]

Bill Gribble <grib@linuxdevel.com> writes:

> On Wed, 2001-11-14 at 09:25, Derek Atkins wrote:
> > They link against it at runtime, not link time.
> 
> This is completely different from the policy we have adopted for other 
> modules.  You can argue with that policy if you want, and if it's broken
> it should be changed, but that's the way other modules work and that's
> how we have been trying to make them all work. The guiding principle is
> that gnc:module-load of a module file should be able to automatically
> load all the dependent modules, which means that they must be linked in
> at library-build time. 

Ok, I've read through the design.txt file a number of times.  It
unfortunately doesn't describe in enough detail (at least for a newbie
like myself) how C code, g-wrap specifications, and scheme code all
fit together to create a gnc-module.  Looking at the engine as an
example, why do there appear to be two modules, "gnucash engine" and
"gnucash gw-engin" and how do they relate to each other?  I still
haven't grokked this part yet.

I do, at least, seem to understand the "use-modules"
vs. "gnc:module-load" thing, although it appears that "use-modules" is
still used within modules.  So I guess I'm still confused about where
and when to use these two functions.

As for the "policy", I think it completely misses the point if any
gnc-module has to link against ALL dependencies.  The reason is quite
obvious: when you have optional plug-in modules, you it's a pain in
the butt to have to link against all the core gnucash libraries in
order to build a side module.  If you're going to require modules to
be linked, why not link everything together at one time?  What's the
point of modularization if all the modules are intertwined in the end?

I suppose what this does give you is a clear layering of modules.  In my
particular case I'm trying to build two modules:
	business-core
	business-gnome

There is a clear delination in that business-gnome depends on
business-core but the reverse is not true.  Other dependencies are
that business-core depends on the engine (and glib), and
business-gnome depends upon the gnome-utils libraries (modules?).  Now
that I think about it, I don't think I actually depend on libgncgnome
(but I'd have to check to make sure).

> Please take some time to try to understand what's going on now, and what
> does or doesn't work about it.  We need to improve and complete the
> implementation and policy surrounding the module system, and we can't do
> that if folks are circumventing it and putting off changes until later. 

As I mentioned earlier, there isn't enough documentation to help
someone build a module.  For example, I had to learn by
experimentation that I had to (export ...) all my symbols...  Isn't
there some way g-wrap can do this automatically?

There is also, as I mentioned, lack of documentation explaining how
and where to use (use-modules) and (gnc:module-load), and how they
interact.  For example, engine.scm uses (use-modules) -- why?  And if
it can use it, why can't I in my modules?

> > I've pretty much tried to copy what the engine and "gnc" modules
> > (Aside: I think 'gnc' is a really bad name for the Gnome interface
> > module!) do.  Note that the gnc module does NOT link against
> > libgncmod-engine.la either...  It does what I do: (use-module (... engine))
> 
> I'm not sure what you're talking about here.  There is no "gnc" module
> that I know of.  The gnome code isn't in a gnc-module at all, but rather
> just a big glom of a shared library, libgncgnome.la.  The 'gnc' g-wrap
> bindings are the last vestiges of the One Big G-wrap File that used to
> be in src/guile; it's called gw-gnc right now, but that's just because
> it will be gotten rid of completely soon and there's no point in
> changing the name just for a couple of weeks.  It's not a gnc-module
> either. 

Ah, so there isn't a 'gnome' module?  Hrm.. Ok, I was confused, then.
I'm still confused about guile vs. gnc modules, but that will just
take time, I think.

> I hope the (use-modules ...) thing was just a typo ... gnc-modules
> aren't Guile modules, they are a separate animal, and you load them
> using (gnc:module-load module-name interface-number).  You certainly
> shouldn't load the engine by a use-modules call.  It's a gnc-module, and
> it runs code in its gnc-module initialization function that won't get
> run if you bypass the gnc-module system and load that guile module
> directly. 

No, it was not a typo.  As I've said, I've been trying to get things
working by copying what already exist.  Many of the .scm files in the
gnucash tree use "(use-modules ...) so I was just trying to follow
suit.  Not having a clear description of the difference has clouded my
judgement, perhaps. ;)

> > Don't I wish -- but no, I need to call into the engine and some of
> > the gnome-utils functions.  In fact, I can't see how this would ever
> > work.
> 
> You need to link against those modules, then.  Please add the test-link
> and test-load-module tests that I described in my previous message into
> your test suite; they will help you debug broken dependencies. 

Ok, I'll try this, once I get the time.  (I will note that my LDADD
line in the test directory is different than the LDADD line in the
module directory).  Right now I'm fighting against multiple versions
of guile interacting poorly.  I'm surprised (and dismayed) that I
can't get around this problem by using the "load-module" as opposed to
"-l".

> Thanks,
> Bill Gribble

-derek

-- 
       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@MIT.EDU                        PGP key available