installation paths, option definition (was: QofBackend changes in next commit)

[Neil Williams]

On Friday 02 September 2005 3:22 pm, Christian Stimming wrote:
> 1. You propose to pass installations paths by a header file.

This is not a new mechanism.

> 2. You propose to separate the configuration option definition from its
> documentation.

? The 'documentation' is where it is because it's translated.

I looked at putting this in the XML but it just isn't worth the effort.

> (And just one nitpicking remark: The auto-generation of a header from a
> header.in file is done by "./configure", not by "automake" -- automake
> basically only creates a "Makefile.in" from a "Makefile.am", but the
> processing of the *.in files is always done by ./configure.)

Not in this case, nor in lots of cases within GnuCash. We use a Guile 
convention in lots of areas that does no substitution during configure, only 
in the Makefile.am using a customised sed routine. 

qsf-dir.h: qsf-dir.h.in
        rm -f $@.tmp
        sed < $< > $@.tmp \
                -e 's:@-QSF_SCHEMA_DIR-@:${QSF_SCHEMA_DIR}:g'
        mv $@.tmp $@

That has been in place for schema validation for some months and also passes 
an installation path by a header file. No problems with that one. It's 
actually more flexible because the output can be updated without a 
complete ./autogen.sh.

Try grepping for sed in Makefile.am's all over the source tree.

$ vi gnome/Makefile.am
## We borrow guile's convention and use @-...-@ as the substitution
## brackets here, instead of the usual @... at .  This prevents autoconf
## from substituting the values directly into the left-hand sides of
## the sed substitutions.
gnucash.keys: gnucash.keys.in ${top_builddir}/config.status
        rm -f $@.tmp
        sed < $< > $@.tmp \
            -e 's:@-icondir-@:${appicondir}:g'
        chmod +x $@.tmp
        mv $@.tmp $@

I guess the only difference is that this header is seeking to be installed. 

> As for #1, that was:
>
> Neil Williams wrote:
> > On my system, this header defines (for cashutil):
> > #define GNC_LIB_DIR "/opt/garfield/cashutil/lib"
> > #define GNC_XML_DIR "/opt/garfield/cashutil/share/xml/cashutil"
> > #define GNC_LIB_NAME "libgnc-backend-file.la"
> > #define GNC_LIB_INIT "gnc_provider_init"
>
> Passing installation paths from one library/application to another by
> this method is actually not-so-common or rather "unorthodox". The usual
> way of passing such installation paths currently is by pkg-config, where
> the library will define variables with the paths in its *.pc file.

OK, I can do that. However, it's just duplicating the existing method which 
will still remain to provide the library name and init function name. I see 
no reason to put that in qof-1.pc

> > GnuCash will need to know where the GNC backend is installed (as it will
> > be shared with cashutil) and will also pick up the location of QSF via
> > #include <qof.h>. So GnuCash uses two such header files, gncla-dir.h
> > (which automake generates from src/backend/gncla-dir.h.in) and
> > qofla-dir.h (from <qof.h>).
>
> In principle that is fine. I'm just a bit confused: GnuCash needs a GNC
> backend?

Yes, because this backend is to be shared with CashUtil which is installable 
without GnuCash. It could, conceivably, be installed outside the GnuCash 
package directories - it's probably best that it is so that CashUtil 
installation doesn't need to mess around in a GnuCash installation. They both 
need libcashobjects.la and libgnc-backend-file.la which can be installed in 
some shared directory under the control of a new package. Straight-forward 
dependencies at the package level (apt-get).

GnuCash has always loaded the gnc file backend as a separate entity, it's just 
it's being prepared to be shared with CashUtil and may not be in the GnuCash 
installation directories for much longer. (i.e. on the user's system).

> Err... can you draw a picture which part depends on which part 
> here, and where "Gnucash GUI", "GNC backend", QSF, and QOF all fit into
> that picture?

The outline picture is here:
http://www.data-freedom.org/explain.html#example

The only difference is that Programs A and B actually use the same backend 
(which makes it kinda hard to draw). A1 == B1 because objects A == objects B. 
However, ProgramA != ProgramB.

PilotQOF calls libqof which provides QSF as no other backend is defined.

Gnucash GUI calls the gnc file backend and adds the QSF backend. Much as it 
has always done. CashUtil does the same. Both GnuCash and CashUtil load the 
objects and ancillary logic from libcashobjects.la which may or may not be 
installed in a GnuCash installation directory.

> In particular, which part depends on which one *at compile 
> time*? That is not a problem, but just a bit confusion on my side.

GnuCash depends on QSF via a dependency on QOF. It also depends on 
libcashobjects.la and libgnc-backend-file.la via the new shared package. i.e. 
the cashobjects and the gnc file backend are being prepared for a separate 
installation from GnuCash - a CashUtil installation. 

GnuCash GUI includes:
QOF (and QSF)
libcashobjects.la
libgnc-backend-file.la

CashUtil includes:
QOF (and QSF)
QOF_SHELL
QOF_UNDO
libcashobjects.la
libgnc-backend-file.la

PilotQOF includes:
QOF (and QSF)
and it will pick up QOF_SHELL and QOF_UNDO later.

> I would strongly suggest that *if* you want to define the 
> options inside the XML file, *then* you should include the description
> and tooltip right in that XML definition as well.

If not? How can the options be defined generically without a separate file? 
You cannot interpret the KvpFrame correctly without knowing which options are 
supported and what data types they represent.

I tried that translation and it proved much more difficult than you seem to 
expect. I'm open to ideas but I do need to know that the final result will 
actually work.

> Otherwise either one 
> gets forgotten or confused with something else or whatnot.

I don't see a problem. You need the XML to understand the KvpFrame. If you 
want the translations, they are in pre-defined keys below the option name.

If you don't want to deal with the backends in a generic fashion, you can 
compile the option names and data types into the C and then have to recompile 
them if they change. Can't believe you want that. This way, if the backend 
changes it's options, IT does the compiling of the translations and you 
simply need to read the updated XML and pick up the translations from the 
KvpFrame.

gnc-backend-file and libcashobjects are SEPARATE from GnuCash GUI now, the 
pair are to be installed as a separate package that is a dependency of 
GnuCash GUI and CashUtil.

This was always the goal of using qof_load_backend_library instead of the 
existing module. I've removed the scheme and now it can be installed 
independently of GnuCash GUI.

It has to be so if CashUtil is going to be installable without GnuCash GUI - 
my primary aim in all my CashUtil work.

IMHO, a CLI that depends on a GUI is not worth the effort. So, CashUtil needs 
to have access to certain non-GUI parts of the current GnuCash tree WITHOUT 
the GUI having to be installed too.

gnucash-common is a separate package but that is the idea, maybe the package 
maintainers will decide to call it gnucash-shared or just cash. Either way, 
this new package is a dependency of both the GnuCash GUI and CashUtil CLI.

> In your 
> current proposal you would split the definition of one option into
> several locations.

The definition is in the XML. The translation is in the library, accessed via 
a KvpFrame.

> IMHO this is simply not necessary. You gain much more 
> code clarity if the definition is contained in one clear location.

IMHO, it is - the XML.

> Note again that the translation question is totally orthogonal to this
> definition location. There are several possibilities on how to organize
> the translation if a UI-string is inside an XML file

I tried most and they are far from simple or reliable for a generic interface.

> , but that would 
> distract from the definition location here, so I'd explain that another
> day. But that's really not complicated.

Please do expand - it was far from simple at this end.

> What's much more important is 
> that the original definition of interfaces is clean and concise, and
> from what I gathered these options are precisely a part of the backend
> interface.

The options are, yes. The translations are more or less a courtesy - they can 
always be overridden by the application if appropriate.

> In summary:
>
> Is it possible to distinguish these two issues from the rest of your
> "next commit" proposal?

Not really, it's hard enough to test with all those #ifdef's around, let alone 
with some changes in one tree but not another.

> From what I gathered, the rest of your work is 
> well thought and can be incorporated into gnucash just fine, but these
> two issues IMHO really need some more discussion.

I don't mind but I do need a solution that will work for an installation of 
ONLY CashUtil - no guile, no scheme, no Gtk or GUI.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050902/3cce4425/attachment.bin