Linking the shared library FOO.la against the loadable module

[Derek Atkins]

Quoting Neil Williams <linux at codehelp.co.uk>:


>> PLEASE PLEASE PLEASE PLEASE PLEASE keep src/business SEPARATE.
>
> ? Hang on a tick. I can go back through the archives if you want, but this is
> old news, Derek!
>
>> DO NOT
>> require src/business to get integrated into src/engine.
>
> It's not. Please take a good look at the breakdown on the CashUtil site,
> gncInvoice goes into a library with Account etc.

NOOOO!!!!!!  That's exactly what I *DO NOT WANT TO HAPPEN*

>   The file stuff goes in with
> the other file backend stuff. The engine goes into QOF. Feel free to take a
> look at the tarball too:
> src/
> src/objects/
> src/backend.
> src/test/
>
> Even the test routines are collected as one.

Egad, no!  Files are segregated for good reasons.

> Not much is going to be left of what is now src/engine - the list is on the
> cashutil website but consists mainly of (redundant) guile/gwrap code and the
> Budgets code that doesn't yet fit well with a CLI, even though it's not
> actually GUI dependent. The other parts are linked against libcashobjects.la
> (a genuine shared library, not another module). This allows GnuCash to link
> all it's GUI code against the objects while CashUtil links all it's CLI code
> against the objects - from the one object library.

libcashobjects should be the core engine objects.  It CANNOT include the
business objects from src/business/business-core.  I was ALWAYS under the
impression that the code layout wasn't changing.  There was never any talk of
moving the code from business-core elsehwere.

So you've got libcashobjects that has the core engine objects, and then there
should be a libcashbusinessobjects which is effectively
libgncmod-business-core.

> There's been a table on the site for weeks listing exactly where each file
> comes from and which objects are supported. It was put up specifically
> because of discussions on this list.

As if I've got the time to go off and read the cashutil site?

> "The existing financial objects, including the business objects, need to be
> collated into a single library that can be shared with CashUtil."
> "The existing GnuCash v2 XML backend, including it's business object 
> handlers,
> also need to be collated into a single library."
>
> These are BOTH now done. 100% complete, tightly integrated and bound.

Sorry, why does it need to be a single library?  Why cant' you keep it 
separate
like it is now?  It was specifically designed to remain separate because we
want to be able to ship a version of GnuCash WITHOUT the business objects.  We
WANT to be able to have a "gnucash-personal" and "gnucash-business" package.

The way to do this is to have a baseline "gnucash" and then a 
"gnucash-business"
which includes the code under src/business.

> The profusion of #ifdef's are an indication of the coalescence of the
> disparate sets of objects and backend components into logical wholes.

Yea, I've noticed them and I was afraid of that...   No, sorry, 
no-can-do.  I do
not want src/business that integrated into gnucash.

> As I've always said, the C files themselves can almost certainly stay exactly
> where they are (for CVS history purposes) but the libraries are different - a
> clear distinction between the objects and the UI code. There can be no code
> from business-gnome etc in with the business objects. The business module -
> the current mix of object, backend and GUI code - is completely incompatible
> with CashUtil.

Where the C code lives is only part of the issue.  How it's built is another
part.   An original goal was the ability to distribute the business objects as
a secondary module, separate from the main body of code.  I think this 
was even
done once, somewhere.

> cashutil currently supports the Split, Trans, Account, GncOrder, gncTaxTable,
> gncVendor, gncJob, gncInvoice, gncEntry, gncEmployee, gncCustomer,
> gncBillTerm and gncAddress database table names. You can use the names with
> cashutil -d and in SQL queries (as the table name) with cashutil -s|f. Use
> '-d <database> --explain' to see the list of fields within any supported
> database.

I really don't want the business objects to live (in a library or a source
directory) with the core engine objects.  I want them to be separate.  Can't
cashutil learn to live with two sets of libraries?

> In fact, recently, that's been extended to SX, commodity and Group.
>
> http://linux.codehelp.co.uk/cashutil/
>
> http://linux.codehelp.co.uk/cashutil/gnucash.html
>
> A further distinction the follows as the ancillary logic expressed in the
> current GUI is abstracted into the common libraries for CashUtil and GnuCash
> to use together. So finally the common libraries include the objects, the
> backend and the logic.
>
>> It's a separate
>> set of modules
>> for a REASON.
>
> (an undocumented reason?)

Oh no, it's been documented and discussed since I first wrote the 
business code
years ago.  The reason is so the business code is separable.  So someone
doesn't have to run with the business code..  So a packager could distribute
the business code separately, in a separate package..  So a user who doesn't
need the business code doesn't need to have it installed.

It's a module in the same way that hbci and ofx are modules, and should be
separable in the same way that gnucash-ofx and gnucash-hbci packages 
exist. The only difference is that there's no configure option to turn 
off the
business objects, and few packagers actually separate it out.  But that 
doens't
mean we should screw over those who do (or want to).

>> Please keep it that way.  GnuCash (and Cashutil) should work
>> just fine WITHOUT the business objects loaded.
>
> Eh? When was this decided? Why? Since when did this become a problem of FOUR
> units? I've built CashUtil for two - ALL the objects together and a single
> file backend to complement QSF.

It was decided when I wrote the code years ago.  It's ALWAYS been a problem of
"four units".  That's the design purpose.  That's WHY the business code is in
sec/business and not src/engine.  That's the whole reason for runtime
plugability.  The keep it all separate.  That's the whole reason QOF 
came to be
-- to support the business modules as a SEPARATE SET OF LIBRARIES.

> The business objects work fine within CashUtil and there's absolutely no
> reason to take them out.

I'm not asking you to take them out of CashUtil.  I'm asking you to 
keep them as
separate libraries.

> Please don't say this is something else you missed in the LONG list of
> discussions on this whole thing. It has been this way on the CashUtil website
> since it started. It clearly states that gncInvoice will be in CashUtil just
> like Account. There is no division available - conceptually or
> programmatically.

Sure there is.  libcashobjects and libbusinessobjects.  The separation 
is there
today in gnucash, and it can remain today in cashutil.

> This is a small utility program, not a toolkit. It doesn't have the
> wherewithall to go around loading objects on demand or even at runtime. The
> backends are enough to deal with and most of that is done via QOF.

Then link against two libraries instead of one.

> There are excellent reasons for having options in the choice of backends -
> there are no clear reasons, in a program this small, for having gncInvoice
> loaded at runtime and Account loaded at compile time. Complete overkill and
> unnecessary complication of the UI.

For cashutil you're welcome to link against both libraries (for now).  When
(if?) it's integrated into the gnucash source tree, it will have to keep the
separation.

> I see no purpose in even writing CashUtil without the business 
> objects tightly
> integrated. There is precious little overhead and no reason to partition the
> list of supported objects. There is absolutely no reason to support separate
> business objects in such a small program - they consist of over 30% of the
> code!

See my previous reasons why.

> Sorry, CashUtil is sticking with one set of objects. It's FAR too late to go
> springing something like this on me.
>
> GnuCash can have a distinction if you want, but CashUtil cannot.

Hmm... I think we're talking cross purposes...  But whatever.  You're coding
cashutil.  You're welcome to keep it in sync as a separate util ad 
infinitum if
you wish.  Personally I'd like to see it integrated into Gnucash, which means
it'll have to load the core objects and business objects separately from two
libraries.

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