installation paths, option definition
stimming at tuhh.de
Sat Sep 3 13:46:55 EDT 2005
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
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
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.
More information about the gnucash-devel