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/
pgp2pY0CTdFHX.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
