Re: GLib headers

[Owen Taylor <otaylor redhat com>]

Sebastian Wilhelmi <wilhelmi ira uka de> writes:

> Hi Tim,
> 
> > > But I would like to rename glib-object.h to gobject.h, is that possible,
> > > Tim, or was there some other reasoning behing that name other than
> > > avoiding gobject.h inside /usr/include?
> > 
> > yes, name conflicts/confusion.
> > there's already gobject/gobject.h which holds the struct GObject
> > implementation and is way different from the inclusion master file 
> > glib-object.h.
> 
> Ok, but it still looks ugly.
> 
> > thanks for doing the header split ups, however there's one thing i
> > want to see reverted, that is:
> > 
> >         * gmacros.h: Added G_BEGIN_DECLS and G_END_DECLS to mean: 'in case
> >         of C++: extern "C" { ... }' analogous to glibc __BEGIN_DECLS and
> >         __END_DECLS.
> > 
> > we decided against that for glib and gtk+ pretty early on after GNOME 
> > introduced their pendants macros.
> 
> Oh, what a shame. Was there some specific reason? I mean, it looks much better
> and all GLib-dependend header files could save some trouble. Furthermore also
> glibc has such macros, so they can't be evil right away. (But I don't want to
> bother you too much. Just shout at me to shut up and I will).

None that I recall... (I don't even recall the discussion)
 
> Still another problem is unsolved:
 
> Owen wants to have all header files in a subdir glib. The best way to achieve
> that would be to move (almost) all *.h,v and *.c,v files from /cvs/glib to
> /cvs/glib/glib (also the gthread, gmodule, gobject subdirs) on the cvs server.
> That would make the glib-structure akin to that of gtk, as such would keep all
> *.c files in the same dir as the corresponding *.h files and would save the
> history for us. I can not do it, as I can't login to cvs.gnome.org (only via
> cvs). So it's obviously up to one of the red hatters to do it.

I can do it - however, I don't want to go ahead with this until there
is some agreement that we actually want to do it.

What I had suggested was simply to move the split-up .h files into
a subdir; this is obviously a less major change. But Sebastian
is right that it would make a lot of sense to move the .c files
to so we have one library per-directory, and the .c files in
the same place as the .h files.

What do you think Tim?

(I'd of course do it by copying the files and then cvs removing
them from their old location so we could still check out old
branches of GLib)

Regards,
                                        Owen