The ability to query information from libfo

How do you want to access the information? Separate function for each parameter? Associative array style lookup of value corresponding to parameter key?

Do you want to know the libxslt/libxml2 version as well?

What about the Subversion changeset number?

Replying to tkg:

How do you want to access the information? Separate function for each parameter? Associative array style lookup of value corresponding to parameter key?

Separate function, better interface.

Do you want to know the libxslt/libxml2 version as well?

yes, becouse someone could link to different version of these. For example have install packages and dev version (svn/cvs).

What about the Subversion changeset number?

yes, need it too.

Replying to incastrix:

Replying to tkg:

How do you want to access the information? Separate function for each parameter? Associative array style lookup of value corresponding to parameter key?

Separate function, better interface.

Something like:

gchar * fo_libfo_version (void);
gchar * fo_libfo_libxslt_version (void);

?

Replying to tkg:

Replying to incastrix:

Replying to tkg:

How do you want to access the information? Separate function for each parameter? Associative array style lookup of value corresponding to parameter key?

Separate function, better interface.

Something like: {{{ gchar * fo_libfo_version (void); gchar * fo_libfo_libxslt_version (void); }}} ?

perfect

Replying to incastrix:

Replying to tkg:

perfect

I'm glad that you didn't want:

void fo_libfo_version (gint *major, gint *minor, gint *micro, gint *subversion, gint *interface_age)

I do still worry that it won't be flexible enough if something changes in how libfo is put together.

And for backend support?

typedef enum
{
  FO_LIBFO_BACKEND_FLAG_NONE = 0,
  FO_LIBFO_BACKEND_FLAG_CAIRO = 1 << 0,
  FO_LIBFO_BACKEND_FLAG_GNOME_PRINT = 1 << 1,
  FO_LIBFO_BACKEND_FLAG_MASK = (1 << 2) - 1,
} FoLibfoBackendFlags;

FoLibfoBackendFlags fo_libfo_get_backends (void);

const gchar * fo_libfo_get_backend_version (FoLibfoBackendFlags backend);

?

The other things that you might possibly need are Pango version and default pixels-per-inch for raster images.

Replying to tkg:

Replying to incastrix:

Replying to tkg:

perfect

I'm glad that you didn't want: void fo_libfo_version (gint *major, gint *minor, gint *micro, gint *subversion, gint *interface_age) I do still worry that it won't be flexible enough if something changes in how libfo is put together. And for backend support? {{{ typedef enum { FO_LIBFO_BACKEND_FLAG_NONE = 0, FO_LIBFO_BACKEND_FLAG_CAIRO = 1 << 0, FO_LIBFO_BACKEND_FLAG_GNOME_PRINT = 1 << 1, FO_LIBFO_BACKEND_FLAG_MASK = (1 << 2) - 1, } FoLibfoBackendFlags?; FoLibfoBackendFlags? fo_libfo_get_backends (void); const gchar * fo_libfo_get_backend_version (FoLibfoBackendFlags? backend); }}} ?

agree

Replying to tkg:

The other things that you might possibly need are Pango version and default pixels-per-inch for raster images.

Great!

IS possible to query backend ver?

Replying to incastrix:

IS possible to query backend ver?

configure checks it to see if it's recent enough, so it should just be a matter of 'pkg-config --mod-version' leading to an #define in 'config.h'.

Replying to tkg:

const gchar * fo_libfo_get_backend_version (FoLibfoBackendFlags? backend);

Does there also need to be:

const gchar * fo_libfo_get_backend_name (FoLibfoBackendFlags? backend);

Replying to tkg:

configure checks it to see if it's recent enough, so it should just be a matter of 'pkg-config --mod-version' leading to an #define in 'config.h'.

That's not going to work for a dynamically linked library. It would have to use whatever API the backend provides for finding the version.

(In [420]) First pass at adding version API. (Re #123.)

(In [424]) Renamed FoEnumFormat? to FoFlagsFormat? so it could indicate multiple values. Added fo_doc_formats_from_name() for getting formats supported by a backend (re #123). Added some CUnit tests. Made xmlroff do case-insensitive matching on backend and format parameters.

(In [425]) Added fo_doc_version_from_name() and fo_doc_version_string_from_name(). (Re #123.)

[427] applied to this. It was not documentation updates.

typedef struct {
  const gchar *nick;
  const gchar *name;
  gint         version;
  const gchar *version_string;
} LibfoVersionInfo;

const LibfoVersionInfo * libfo_version_backend_info (void);

isn't what I offered before, but would it do the job? (I am still working on it.)

(In [429]) Backend runtime version info now available from libfo_version_backend_info(). (Re #123.)

My current thought is something more like:

typedef enum {
  LIBFO_MODULE_XSL_FORMATTER,
  LIBFO_MODULE_XSLT_PROCESSOR,
  LIBFO_MODULE_BACKEND,
  LIBFO_MODULE_PANGO
} LibfoModuleEnum;

typedef struct {
  LibfoModuleEnum module;          /* Type of the module */
  const gchar    *nick;            /* Nickname for human consumption */
  const gchar    *name;            /* FoObject type name, e.g., FoDocCairo */
  gint            compiled;        /* Compile-time version number */
  const gchar    *compiled_string; /* Compile-time version number as string */
  gint            version;         /* Runtime version number */
  const gchar    *version_string;  /* Runtime version number as a string */
} LibfoVersionInfo;

const LibfoVersionInfo * libfo_version_get_info (void);

where libfo_version_get_info() returns an array of LibfoVersionInfo (where the last item is all NULLs and 0s), and you can pick over that to find the version information of the components of libfo.

There would, for example, be multiple LIBFO_MODULE_BACKEND entries when multiple backends are available.

It also means the API doesn't have to change if we come up with new components for libfo. (One day there will be loadable modules that can tweak the formatting, but we're still unfortunately a long way from that.)

I haven't quite worked out what it would mean for this function if, for example, the backends were loadable modules. I think the version API would have to report all that are available, even if it means loading them just long enough to get their version info.

I am ambivalent about providing the libxml2 version because that's not such an active part of libfo.

LIBFO_VERSION_MAJOR, etc., and libfo_version() would remain for use when all you really want to know is the libfo version.

(In [433]) Next rendition of a version interface for libfo components. (Re #123.)

libfo_version_get_info() returns an array of pointers to LibfoVersionInfo structs.

Currently only implemented for the two backends, and the CUnit test will fail if you don't have both backends enabled.

(In [434]) Hopefully the final attempt at a version API. (Re #123.)

I've done as much as I intend to do. Please see if it does enough for your purposes.