Re: [PATCH] Clean up `glibconfig.h'

[Raja R Harinath <harinath cs umn edu>]

Tim Janik <timj@gtk.org> writes:
> On 25 Oct 1998, Raja R Harinath wrote:
> > I have uploaded 
> > 
> > 	glib-rrh-19981025-0.patch.gz
> > 
> > to ftp.gtk.org:/incoming.
> 
> ok, i just read through your patch and only found a few minor issues:
> - g_memmove, please still provide the exact prototype of this function
>   in the comment (so one doesn't have to look it up in glibconfig.h), i.e.
>   void g_memmove(gpointer src, gpointer dest, guint size).

OK.

> - g_ATEXIT/ATEXIT, is this really worth keeping? use of this macro is
> abandoned for a variaty of reasons (glib shouldn't provide macros
> outside of it's namespace and use of ATEXIT() still requires system
> dependant header files which may vary depending on the target
> platform). i'd rather see ATEXIT() to completely vanish, since we
> provide a function g_atexit() that takes care of portability issues.

I thought about this.  I kept it just to be compatible with current
glib.h.  I won't mourn losing it.

> - why are the #include <config.h> lines wrapped by an #ifdef HAVE_CONFIG_H
>   statement? with your new scheme, glibconfig.h and config.h are always in
>   place.

Just out of practise, I guess.
   
> ok raja, except for the above issues, i think your patch should be applied.
> but since a few checks in gdk need to be changed aftewards, and snorfle's is
> going to make a new release of gtk which will depend on the glib 1.1.4 from
> last weekend, we'll have to wait for the upcoming gtk release to be made.

Ok.

> since you have commit access to the repo (and are touching virtually any cvs
> module's auto* section anyways ;), 

Hey, I resemble that remark ;-)

> i'd like to see you commit this stuff yourself next time, rather than
> providing a new patch.
 
Will do.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash