option definition

Sat Sep 3 15:13:10 EDT 2005

On Saturday 03 September 2005 6:46 pm, Christian Stimming wrote:
> > 	MY_LIB_DIR=`$PKG_CONFIG --variable=libdir package`
> > 	MY_XML_DIR=`$PKG_CONFIG --variable=xmldir package`

> Ok, that's much more "standard-like". Thanks for that.

No problem.

> 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.

Interesting, I'm also on a Debian list and one comment there was that source 
tarballs / upstream shouldn't be using .pc files, leave it to the packagers. 
I'm sticking with the .pc but, for completeness, is there any consensus here 
about the name of the pc file?

From my Debian message:
The upstream tarball is qof-0.6.0.tar.gz, the SONAME is 
libqof1, the package libqof1 and I want libqof1 >= 0.6.0 as a dependency for 
packages that use the library (something pkg-config does quite nicely).

Currently, the .pc file is qof-1.pc which probably needs to be changed.

Taking this as an example, what *would* be the recommended name for the pc?

Should it include the SONAME at all?
Should it always use the lib prefix?
Is there any convention on these filenames, independent of any distro?

So, opinion please. Should I use qof1.pc, qof-1.pc, libqof1.pc ? I really 
don't mind which - the previous release had qof-0.pc

> 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.

Hadn't thought of it from that direction, thanks.

> > 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. ...

This is proving awkward. :-)

> Wait a second. When reading your original description again
> https://lists.gnucash.org/pipermail/gnucash-devel/2005-September/013608.htm
>l 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.

That code can be improved, yes. 

> 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. 

This is leading to generating the XML from the C, somehow, maybe during the 
build. That's what I tried first with the perl and it isn't easy because the 
translations happen at runtime, not compile time. Generating the XML from the 
library can be done, of course, but to handle the translations as well 
involves perl modules that most users simply won't have installed. There 
needs to be another way.

> Can you please 
> elaborate how you intend to avoid inconsistencies between the XML file and
> the C source?

Todo.
:-(

A natural weakness in moving away from the perl method to a static file 
created by the backend developer.

I can probably load the XML into the backend C or generate it from the C but 
other backends would then need their own libxml dependency, even if they 
don't use XML.

This whole thing needs a rethink. Ideas welcome!

> 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.

Yes. My concern is when the string is in the XML but not in the C - then 
gettext becomes awkward. The perl script was one idea but had problems. 
Creating or reading the XML directly also has problems.

Maybe we should ditch the XML altogether and rely only on the KvpFrame and 
some API method of determining which keys are present?

The requirements are:

1. A generic option interface that can handle any number of allowed KvpValue 
option types each with a unique const char* name.
2. Descriptions and tooltips to be translatable and passed in the KvpFrame 
using standardised paths based on the above option name.

What about using standard / API Kvp paths for the whole thing?

Key backend_option1 has the string value "file_retention_days".
Key backend_option1/file_retention_days contains a gint64 value.
Key backend_option1/file_retention_days/desc -> Translated description
Key backend_option1/file_retention_days/tip     -> Translated tooltip.

Then just iterate through by concatenating a counter onto the stub: 
"backend_option" ? The next one is "backend_option2".

Or even backend/option2/...

I can code that into QOF so that the backend just passes details of the 
requested data type and option name in a series. QOF then creates the above 
KVP frame and returns it at the end of the series.

?

(off the top of my head and not necessarily workable)

void qof_backend_prepare_frame(QofBackend *be);

void qof_backend_prepare_option(QofBackend *be, 
	KvpValueType type, const char* option_name)

KvpFrame* qof_backend_complete_frame(QofBackend *be);

That could work. (Using QOF to create the frame at least encourage different 
backends to use the one set of standard paths. They can, naturally, make 
their own.)

Maybe create a struct:

typedef struct QofBackendOption_s {
	KvpValueType type;
	const char *option_name;
	const char *description;
	const char *tooltip;
}QofBackendOption;

void qof_backend_prepare_option(QofBackend *be, QofBackendOption *option);

Then a conversion routine from the KvpFrame back into maybe a GList of 
QofBackendOptions. Maybe even use a GList as a basis for a foreach to create 
the option frame in the first place. (But then we might not need the KvpFrame 
at all, just the types .....

lots of pondering required . . . . . 

-- 

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/20050903/7b123f74/attachment.bin