option definition (was: QofBackend changes in next commit)
linux at codehelp.co.uk
Fri Sep 2 12:54:12 EDT 2005
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
> 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
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
> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050902/5deb2374/attachment.bin
More information about the gnucash-devel