Re: GIO API review

[Alexander Larsson <alexl redhat com>]

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.

> I would even argue that it makes most sense to keep all opaque typedefs
> in one single file and include that from "gio.h" and from each source
> file within GIO. This way you can avoid including any headers from
> headers at all and it makes things so *very* much easier to maintain.
> We changed all of GIMP to this policy a few years back and never had
> a single (!!!) problem related to includes ever since.

I'm not sure this is all that much cleaner. But if we go with the one
global header we can switch to this later as we please.