Re: GIO API review

[Alexander Larsson <alexl redhat com>]

On Thu, 2007-12-13 at 14:50 +0100, Michael Natterer wrote:
> Alexander Larsson wrote:
> > On Wed, 2007-12-12 at 16:46 +0100, Michael Natterer wrote:
> >> Alexander Larsson wrote:
> >>> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: 
> >>>> Hey everybody,
> >>>>
> >>>> We've been doing a GIO API review in the last couple of days and
> >>>> here is the list of comments and issues we've come up with:
> >>>>
> >>>>
> >>>> General:
> >>>> ========
> >>>>
> >>>> It seems GIO allows individual files to be included, this should be
> >>>> avoided like gobject does it:
> >>>>
> >>>> #if !defined (__GLIB_GIO_H_INSIDE__) && !defined (GIO_COMPILATION)
> >>>> #error "Only <gio.h> can be included directly."
> >>>> #endif
> >>> Why? I know gobject does this, but I never understood why. It seems to
> >>> just make build times longer.
> >> Because otherwise you get into the very same typedef and include mess
> >> we have in glib and gtk+. It makes it *very* hard to change anything
> >> type related in the future. Any addition of a new function that happens
> >> to use a new type which was not used in that header before might work
> >> fine for the library's build itdelf, but might break the build of
> >> applications that include whatever combination of headers.
> >>
> >> Clear structure of headers and types should never be traded for compile
> >> time, we also keep distinct things in distinct .c files. Why would we
> >> scatter our typedefs across our libraries, or keep certain includes in
> >> headers forever?
> > 
> > Ok. I guess this makes sense. I'll do this.
> 
> Thanks :-)
> 
> I forgot to mention, gobject has its common header in glib/. I'm not
> quite sure about this decision and I'm also not sure if saying
> 
> #include <glib-io.h>
> 
> or
> 
> #include <gio/gio.h>
> 
> is the more "natural" thing to do... Just for consideration.

I'm for <gio/gio.h>. It seems more inline with all our other libraries.
Only gobject does the <glib-object.h> thing.