Re: GLib headers

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On 26 Oct 2000, Owen Taylor wrote:
> 
> > 
> > Sebastian Wilhelmi <wilhelmi ira uka de> writes:
> > 
> > > > 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)
> 
> we discussed that back when gnome introduced them and someone like
> miguel or elliot asked for moving them to glib. sorry, dunno the
> exact medium/forum anymore either.

Well, if we can't think of why we didn't want them, perhaps we
should reconsider adding them?

> > > 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?
> 
> 1) only move header files with their .c files, i hate source tree
> layouts where e.g. prototypes of one and the same function are kept
> in different directories.

Actually, I do to. Endless typing of ../../include ...

> 2) what's the reasoning behind moving gobject/gmodule/etc into a
> glib/ subdir as well? i think just having
> glib/glib/gmessage.[hc] and friends
> glib/gobject/gsignal.[hc] and friends
> glib/gmodule/gmodule-os2.[hc] and friends
> etc.
> makes most sense.

Moving or not moving? The reason I would NOT want to move
the other libraries are:

 - Shallower, and thus more convenient tree to work in
 - Consistency with GTK+
 - Consistency with the installed headers
 - Consistency with docs/reference/

And I just think it makes more sense to have one library
per subdirectory, than to have one  subdirectory that 
has a library, and then subdirectories of that with more
libraries.

> don't move glib/ChangeLog btw, i'd still want that to apply to
> glib/glib and glib/* general stuff.

Yes, we definitely need a toplevel ChangeLog, and I wouldn't
want to have to go through all 11,000 lines of ChangeLog
and split them apart...

                                        Owen