Re: glib.h: defining functions in header file
- From: Matthew Ahrens <mahrens cs brown edu>
- To: gtk-devel-list redhat com
- Subject: Re: glib.h: defining functions in header file
- Date: Tue, 29 Jun 1999 23:27:04 -0400 (EDT)
On Tue, 29 Jun 1999, Scott Michel wrote:
> By using Glib, you've bought into a framework. Now you're saying
> that you wish the framework was slightly different so that it could
> be used outside the original framework. Sounds like the beginning
> of a holy war...
I'm not trying to start a holy war. I admit that my experience with Glib
is probably less extensive than that of many people on this list. However,
for several projects I have used just the "GLib Fundamentals" macros, and
none of the symbols from the shared library. I was not aware that this use
was "outside the origional framework" of glib. Could you explain what the
"origional framework" of glib is (or point me to an explanation)?
> Perhaps the functions you want to use could be better modularized
> so that you might be able to link with fewer dependent libs, but
> the functions and macros rely on the Glib headers and library. There's
> no way to get around that, per se, other than abandoning Glib as
> your app's framework.
The macros *that I want to use* do not rely on the Glib library.
In conclustion:
I assert that there is a subset of the glib headers which can exist and
serve a useful purpose on its own, namely those described in the "GLib
Fundamentals" section of the reference manual. These macros could be
removed from glib.h and put in their own header file. This new header file
would depend only on glibconfig.h, not on glib.h or libglib.so. This new
header file could be used as an independent subset of glib. I do not
believe this to be a controversal statement. However, actually doing this
is definately debatable, and I do not feel qualified to say that it would
be best overall to implement this suggestion.
--matt
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]