backend-file loading check; reasons for gncla-dir.h?

[Neil Williams]

On Friday 21 October 2005 9:48 am, Christian Stimming wrote:
> In the current 
> gnucash, the whole program will fail if that backend-file hasn't been
> loaded. So can you please make a check for this a fatal assertion for
> now? That will make the source of the problem much more obvious than the
> weird "namespace error" messages.

I'll try and get that done over the weekend - I'm concentrating of QOF 0.6.0 
final release today. QOF remains my main focus, I have relatively little work 
left in GnuCash.

> And nevertheless I still don't fundamentally understand the need for
> passing directory names by C header files. I would still think we were
> better off if none such mechanism would be needed.

Principally it is to allow non-standard installs and separation of these 
modules into separate installations. File locations can only be discovered at 
configure time and when a GModule (like QSF) can be installed *entirely 
separately* to the application, the application needs to discover where to 
find the module. These GModules are no longer "our" libraries (they aren't 
libraries at all, but true modules) - we don't necessarily control where (or 
even IF) they are installed so we have to find out. We do this by either 
determining our own libdir for our own modules (GNC_LIBDIR) or asking the 
external package for it's module dir with pkg-config. e.g. in QOF, the 
location is exported using pkg-config and that string is used to generate 
QOF_LIB_DIR. Other packages could provide their own GModule QOF backends. 
Applications like pilot-qof that use the default QOF backends and no custom 
written ones (like gnc-backend-file) will simply inherit these new modules as 
and when they are installed with not even the need to recompile pilot-qof.

The reason for the C header is that we aren't linking against these modules, 
so we cannot rely on the usual automake principles to find the modules. We 
know that linking against these modules is not portable, so we have to load 
them from the C code and to load we first need to find them.

This will become even more important with the libgda plugable backend planned 
for QOF 0.7.0 which will provide one backend interface for multiple (user 
selected) database plugins.

We can no longer assume the locations of any QOF backend libraries - this is a 
deliberate (and permanent) switch and has multiple benefits in flexibility, 
and codebase reduction and allows users to only install the components they 
actually need.

Up until now, GnuCash has not used genuine modules - they are specialised 
shared libraries that cannot be easily removed from the build or added later. 
GModules allow QOF to accept whatever GModule backend the application 
requests - whether or not the original module was compiled from gnucash code. 
We could not do this before glib-2.0 (hence the gnc_module code) but there is 
every reason to do it properly from here on. In fact, there are good reasons 
to replace all current gnc-module code with GModule code.

The only thing I want to get rid of from the current method is the reliance on 
sed. We don't need it here, the directory headers can be auto-generated 
from ./configure but there is an embargo on adding non-Makefile files to the 
AC_OUTPUT in gnucash. In QOF (and other such programs), these files are 
created in AC_OUTPUT. It works fine (with or without opt-style-install 
options). 

All the problems you and David have experienced are a result of 
gnucash-specific build issues - NOT with the use of directories in a C header 
or the wider use of GModule.

I've already got packages that use this method - make distcheck and binary 
package installation works fine, it's simple, flexible and with a sensible 
build structure, it is problem free.

> Not to mention the fact that this is surely not at all part of the
> changes that are "essential" for the initial gnucash-2.0.0 release.

It is an essential part of enabling QOF to operate externally, eliminating all 
that code duplication. It is, therefore, something that was agreed as worth 
doing in G2.

QOF will not operate externally without the GModule apparatus - the only 
alternative is to use Guile and gnc_module which is simply unacceptable.

GModule is clearly part of what G2 requires - external QOF based on glib-2.0.

> Ceterum Censeo [1] this and similar fundamental changes in src/engine/
> which are non-essential for gnome2 should be done on a separate branch,
> *not* on the branch that is intended to reach a gnome2-release as soon
> as possible.

For the umpteenth time, there is no point because it is all now done. I expect 
this to have been my last large commit to G2. G2 does now run with an 
external installation of QOF and the QOF files in the gnucash source tree 
only exist for two reasons:

1. CVS cannot move the files to the eventual lib/libqof/ directory without 
losing history.
2. Anyone who doesn't have QOF available (not many once 0.6.0 is out) can have 
it compiled internally.

QOF v0.6.0 will be available on all Debian-based distributions long before the 
time G2 is ready for release, it compiles on FC3 and I expect no problems 
getting it available for any platform that chooses to use it, including OSX. 
I'd expect most maintainers to take the opportunity to use an external 
library when packaging G2, especially when it is also used by GnoTime and new 
applications like pilot-qof.

I fully expect my future work in G2 to consist only of:

1. Updating QOF files prior to each release (more frequent than gnucash 
releases) - this may involve substantial changes to the QOF files in 
src/engine (and later lib/libqof) but these will always retain API 
compatibility with current QOF 0.6.0 - until such time as libqof2 is ready 
when I'd expect gnucash to be on at least 2.1 or 2.2. Most changes will 
simply be deprecating old code.

2. bug fixes

3. Minor extensions to how QSF is used - one or two new dialogs.

4. cashutil.

As I've said before, cashutil is not even of concern until a while after G2 is 
out - it's a long way from ready and I have far more pressing demands within 
QOF. Therefore, I am only concerned with 1 and 2. As 3 is minor it will 
certainly wait until a later release.

-- 

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/20051021/ef73e551/attachment.bin