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

[Christian Stimming]

Errr... sorry, Neil, but you're proposing some quite substantial changes 
here, and maybe it's only me, but some of these changes make me feel a 
bit uneasy.

In particular, two parts of your proposed multi-part changes seem to me 
a bit problematic. And as they IMHO might be quite hard to change once 
they have been introduced, I would rather ask whether you can defer 
these two parts of your proposed commit to some later time and spent a 
bit more time on discussing these. In particular:

1. You propose to pass installations paths by a header file.

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

(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.)

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. The 
application which wants to access these paths will have some code in its 
configure.in script which will retrieve these paths via pkg-config at 
./configure time. That code in turn will define C constants which are 
either put into the config.h of the application or will directly be used 
by passing -D arguments to gcc, but that is totally up to the application.

I must admit that I can't tell the exact reason right now *why* these 
paths should better be passed via pkg-config and ./configure (maybe 
Derek knows better). But that is pretty much the standard way of passing 
such things, whereas defining them as C constants in a header file is 
quite non-standard. I would rather prefer to stick with the standard way 
and try to avoid to invent a non-standard way of passing such arguments.

> 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? 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? In particular, which part depends on which one *at compile 
time*? That is not a problem, but just a bit confusion on my side.

As for #2:

> The configuration options can be modified without recompiling code for a 
> generic option dialog because once you have the location of the XML file it 
> can be loaded and used to parse the KvpFrame.
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <qofconfig xmlns="http://qof.sourceforge.net/" >
>   <backend name="GnuCash Backend Version 2">
>         <option type="gint64" name="file_retention_days" />
>         <option type="boolean" name="file_compression" />
>   </backend>
> </qofconfig>

This proposal means that the definition of an option will be separated 
from its documentation. I think this should rather be avoided. It seems 
to me that the translation question (which is totally orthogonal to the 
definition and documentation place) distracted you here from a clean 
design. 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. Otherwise either one 
gets forgotten or confused with something else or whatnot. In your 
current proposal you would split the definition of one option into 
several locations. IMHO this is simply not necessary. You gain much more 
code clarity if the definition is contained in one clear location. 
That's one of the places where the scheme files were actually a very 
nice feature of gnucash.

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, but that would 
distract from the definition location here, so I'd explain that another 
day. But that's really not complicated. 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.

In summary:

Is it possible to distinguish these two issues from the rest of your 
"next commit" proposal? 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.

Regards,

Christian