On Friday 02 September 2005 5:29 pm, Derek Atkins wrote: > > This is not a new mechanism. > > No, but it's not recommended. If you had built CashUtil as part of the > GnuCash > source tree then I'd consider it more acceptable (because it's all part of > one source tree package). But being external..... No, I'm not convinced > that passing configuration in a header file is necessarily the right > method. Note that 'config.h' is *NOT* installed!
So should the name of the library and the name of the init function be in qof-1.pc or should those who want that information put it into their files themselves? After all, it's hardly configuration - the filename isn't likely to change and the function name is part of the API. I don't mind putting the directory in qof-1.pc (and something similar for libgnc-backend-file.la so that CashUtil can find it). What about the QSF XML schema location? Should that go in qof-1.pc too? That is also installed by QOF (using a .h) currently. > >> 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. > > I think Christian's point is that you put the english text in the XML > file Ah! Didn't realise that. > , but > then load the translations elsewhere. How does that work with gettext? Doesn't gettext have to have somewhere in the C file to place the translation? > That way the definition and the > description are always kept together. You don't use XML's language > support, but you do use XML to keep the documentation for the options. > > The process at runtime would be: > > load the XML > read the description out of XML > translate the description using the translation files So what reference is in the translation files and where does gettext put the translated strings? > > 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). > > Neil, you really need to differentiate between build/source requirements > and runtime/packaging requirements. You seem to continually drive > development based on the latter, which is like the tail wagging the dog. I am conscious of the runtime/packaging requirements, yes - after all, I need to be able to package this myself eventually. The code does need to support the eventual packages and be shared with CashUtil - I guess I'm not sure where you'd put the dividing line. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpAd1jIE3TUx.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel