Re: PROPOSAL: revise GLib message system

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

[ sssnnnniiiiipppp - (I, anyways, have a delete key ... ;-) ]

> since i'd like to get into actuall implementation of the above stuff,
> do people still have strong objections about enhancing g_warning() and
> friends with a special per-library define of -DG_LOGGER_DOMAIN="somestring"?
> owen, i'm especially wondering whether you still insist on the G_WARNING
> indirection.

Indirection? I don't insist on the uppercase, I do insist on having
a g_log() backend. I'm sort of of mixed minds about making g_warning
do different things in different places. It is decidely handy, but
also definitely  slightly evil.
 
> BTW: i have commited the GModule wrapper code to glib now. the dlopen()
>      implementation works farely well so far, and the HP-UX code should
>      only need minor adaptions if any. unfortunately i can't test that...
>      i'd like to get this stuff going on as many systems as possible, and
>      i have sample implementations for AIX, Next, Windows and probably
>      else systems laying around (the Dynaloader of Perl does a fair job wrt
>      support of different platforms). it's just a matter of someone giving
>      me a hand on system specific implementations, or supplying me with
>      a temporary account on systems that don't use dl* or shl_* stuff
>      (though getting this to work under windows just requires me to
>      erase one of my harddisks and install that <zensored> OS on it ;( ).
>      feel free to proof-read, check and flame about the stuff that's
>      hiding in glib/gmodule now ;)

A few comments on the module API:

/* retrive a symbol pointer from `module', returns TRUE on success */
gboolean        g_module_symbol            (GModule             *module,
                                            const gchar         *symbol_name,
                                            gconstpointer       *symbol);

* gconstpointer *symbol? Is that really equivalent to const void **symbol?

And, why not just return a NULL pointer for error.

Also, g_module() is basically very close to dlopen() - perhaps
we should make the API identical to dlopen(), since that is
becoming very much the standard API now. Perhaps call it
g_dlopen(). What do we gain with the current GModule stuff?
(Just curious...)

>      owen, could you give me some input on how to integrate that
>      gmodule stuff with the AM_PATH_GLIB macro? i guess the best thing
>      to do is to provide AM_PATH_GMODULE (in glib.m4), which uses
>      AM_PATH_GLIB internally and then provides GMODULE_CFLAGS and
>      GMODULE_LIBS (and probably GMODULE_LDFLAGS for systems that need
>      stuff like e.g. -rdynamic) on top of that...

I'd add an extra argument to AM_PATH_GLIB, something like the
list of libraries you pass to gtk-config. (If you need help
with shell/m4 for this, let me know)

Regards,
                                        Owen