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/
pgpJlYURjU3Ma.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
