Re: PROPOSAL: revise GLib message system

[Tim Janik <timj gtk org>]

On 10 Aug 1998, Owen Taylor wrote:

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

erm - typo, from converting gpointer->gconstpointer... ;)

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

well, i'd like to be able to slightly extend the API in the future if
so desired, e.g. featuring special search paths and such.
also, currently the g_module() interface features special function
names on all modules except Main, to have special initialization
and deinitializaion code called. this is test-implemented for
libgplugin_b.c:

G_MODULE_EXPORT gboolean
g_module_check_init (GModule *module)
{
  g_print ("GPluginB: check-init\n");

  return 0;
}

G_MODULE_EXPORT void
g_module_de_init (GModule *module)
{
  g_print ("GPluginB: de-init\n");
}

if a modules defines such function names, "g_module_check_init" is called
upon g_module_open() and provides means for considering the module loading
operation erroneous by returning a value != 0. this fucntion can be usefull
for implementing inter-module dependancies (e.g. libgplugin_b.c could
automatically load an imaginary libgplugin_c.c taht it depends on) or
version checks (e.g. by testing "glib_major_version" or
"myprog_modules_required_release" from the main program).
"g_module_de_init", if provided, will be called prior to unlinking.
for the future, we might even want to feature global C++ constructors
and somesuch (though i don't know whether that is even possible from
C), and thus i think it is better to have an own individual name for
the glib mechanism.

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

well, since you wrote glib.m4 in the first place, help would be
greatly apprechiated. i just glanced at the current glib.m4 and figured
i can't even tell what most of the stuff does without a few hours
investigation ;)

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ