thanks, I think this should be fixed now:

commit 31a9726506668184e0a3b0044cf74a08fe219c0e
Author: Robert Bragg <robert@linux.intel.com>
Date:   Thu Nov 28 12:34:45 2013 +0000

    build: fix building introspection data
    
    This fixes the build with --enable-introspection. I'm not sure why
    g-ir-scanner seems to parse all public headers in isolation instead of
    being able take a more limited list of top-level public headers and
    automatically parse all necessary #include directives but this means we
    have to special case how we define and undefine __COGL_H_INSIDE__ to
    subvert the guards we have in place for detecting misuse of the headers.
    
    Reviewed-by: Neil Roberts <neil@linux.intel.com>
    (cherry picked from commit e0b2255876c1cf11d124d5ae37cbe9a6e43777f1)

Yep, confirmed.  I've untagged cogl and resumed tracking the cogl-0.18 branch:

https://git.gnome.org/browse/gnome-continuous/commit/?id=f9ad39f46e34883149b5018e7729f0cb87dd51f8

Yeah...g-ir-scanner could use a mode where it followed #includes, it's just a little tricky to determine what's a "system" header or not.  (Consider cases like evolution-data-server where the build has two built libraries, one that depends on another).

(In reply to comment #2)
> Yep, confirmed.  I've untagged cogl and resumed tracking the cogl-0.18 branch:
> 
> https://git.gnome.org/browse/gnome-continuous/commit/?id=f9ad39f46e34883149b5018e7729f0cb87dd51f8

Thanks

> 
> Yeah...g-ir-scanner could use a mode where it followed #includes, it's just a
> little tricky to determine what's a "system" header or not.  (Consider cases
> like evolution-data-server where the build has two built libraries, one that
> depends on another).

I wonder if it could perhaps combine using a white list of package headers with following #includes. It could follow headers as the primary means of parsing all of the public api but at each include cross reference with the white list of package headers that we currently declare to avoid system headers.