installation paths, option definition

[Christian Stimming]

Dear Neil,

Am Samstag, 3. September 2005 13:44 schrieb Neil Williams:
>> 1. You propose to pass installations paths by a header file.
>
> OK, it's changed. It's still used for some internal roles (although that
> may change).
> [...]
> The location of the library and the location of the backend config XML file
> is now part of the pkg-config and can be retrieved with:
> (example only)
> 	MY_LIB_DIR=`$PKG_CONFIG --variable=libdir package`
> 	MY_XML_DIR=`$PKG_CONFIG --variable=xmldir package`
>
> The name of the library and the name of the init function are expected to
> be hard-coded into whichever applications need to use them.

Ok, that's much more "standard-like". Thanks for that. Simple rule of thumb: 
If it's an installation directory that needs to be passed from one library to 
another, then pkg-config is the best way to do this currently. 

One simple reason is this: An application might want to use that directory in 
other places than C source code. If you pass it by a C header file, you 
enforce that it can be used by a C source file only. Whereas if you pass it 
by pkg-config, then ./configure of the application knows it and can use it 
whereever the application want to -- e.g. by config.h into C source code, or 
right in the Makefiles, or by a similar config.h-mechanism in other 
programming languages.

Anyway, thanks for adapting that.


> > > >> 2. You propose to separate the configuration option definition from
> > > >> its documentation.
> > >
> > > I think Christian's point is that you put the english text in the XML
> > > file then load the translations elsewhere.
>
> I still can't see how this can work. gettext AFAICT won't load the
> translations that way.
>
> All I can see to do is have duplicate strings in the C and XML - I'd rather
> not do that. 

No, surely not -- I don't want anyone to create duplicated strings. Derek was 
right: I would prefer if the english text of the "description" and "tooltip" 
is in the XML file, just as the name and type of that option. ... Wait a 
second. When reading your original description again 
https://lists.gnucash.org/pipermail/gnucash-devel/2005-September/013608.html
you hopefully don't mean that an option already is *defined twice*? From your 
souce code example I saw that you define an option by writing those lines 
into your XML file:
  <option type="gint64" name="file_retention_days" />
but then in your function gnc_file_be_get_config(QofBackend *be) you create 
the KVP frame which represents the option by adding kvp_values one-by-one. 
The names are chosen by your #defines, i.e. they are string constants in the 
C file, and the types are chosen by the respective kvp_frame_set_xy 
functions. In other words, the creation of your kvp_frame has to manually 
duplicate the things that are written in the XML file. Did I understand this 
correctly? That is, errr, probably not so good. Can you please elaborate how 
you intend to avoid inconsistencies between the XML file and the C source?

> If gettext needs the english text in a C file, there seems
> little point duplicating it in XML.

As for the gettext/translation question: Eventually, translating a string by 
gettext only means that you pass *one* "const char*" into the gettext() 
function and you get *another one* "const char*" returned. That's all you 
need to know. Sorry, I don't have more time now, but I can code up an example 
how that would look like later.

Christian