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

[Neil Williams]

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/

-------------- 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/20050902/5deb2374/attachment.bin