Why? Gtk doesn't export any Objective-C, only C. AppKit.h is exported only by the private gdkquartz.h header; if you're including it directly in your project, then setting up CFLAGS appropriately is your problem. (The option, by the way, is -xobjective-c.)

gdkquartz.h is not private, this file is installed and contains API free for all to use.  I am still wondering about the correct approach with regard to the pkgconfig files, should we put this in the default gdk-3.0.pc *or* have a gdk-quartz-3.0.pc just like there is for X11 (but not Win32).  Need to figure out the reasoning behind the X11 pkgconfig files before I can answer that I think.

OK. How about moving "#include <AppKit/AppKit.h>" out of gdkquartz.h to the three c files that include gdkquartz.h (2 other c files already include AppKit.h on their own)?

My concern is that including -xobjective-c in a pc file will cause downstream introspection errors.

(In reply to comment #3)
> OK. How about moving "#include <AppKit/AppKit.h>" out of gdkquartz.h to the
> three c files that include gdkquartz.h (2 other c files already include
> AppKit.h on their own)?

Then we need to define NSWindow, NSView, NSEvent ourselves in gdkquartz.h (with a kind of dummy define), which might trigger its own series of problems.  For the NSInteger, CGFloat typedefs, another solution will have to be found as well in that case.

> My concern is that including -xobjective-c in a pc file will cause downstream
> introspection errors.

-x is a valid GCC option (also on non-Apple GCC), I don't see why the introspection people refuse to support that.  If the language after -x is not supported, then perhaps just silently refuse the parse the file?

Yup, I didn't think (or look) hard enough about why gdkquartz.h includes AppKit.h.

Dummy defines would definitely not work: The whole point of gdkquartz.h is to provide access to the underlying Cocoa objects.

But in order to use those objects, the program including gdk/quartz/gdkquartz.h must either use objective-c itself (in which case its own CFlags must include -xobjective-c) or include objc/Runtime.h and use the C access methods. Any programmer who knows about *that* is going to know about -xobjective-c, and also that he's going to a lot of extra work for no particular benefit.

Meanwhile, the vast majority of gtk programmers who are just trying to get their apps to build on OSX and who aren't messing around with gdkquartz.h have an extra compile flag gratuitously inserted into their CFlags that breaks introspection.

The introspection folks don't refuse, they just aren't interested in working on it. See bug 626995.

(In reply to comment #5)
> But in order to use those objects, the program including gdk/quartz/gdkquartz.h
> must either use objective-c itself (in which case its own CFlags must include
> -xobjective-c) or include objc/Runtime.h and use the C access methods. Any
> programmer who knows about *that* is going to know about -xobjective-c, and
> also that he's going to a lot of extra work for no particular benefit.
This issue emerged for me (as linked in the original report) when I submitted some code to pygtk to wrap the gdk_quartz_window_get_nsviewget_nswindow methods. The pygtk framework itself does not use objective-c, it only needs the structure definitions. Basically, since the appkit/objc dependency is introduced by gtk (or more precisely gdk-quartz), I think that is is the most appropriate place to define specific CFLAGS).

PyGtk only needs the structure definitions? Here's a quote from NSWindow.h:
"    /*All instance variables are private*/  "
So beyond exposing platform-specific internals in gtk-quartz, you intend to operate directly on private member variables?  

How is this a good idea?

I badly expressed things. Let's rephrase: to embed external windows (say a video player) into my pygtk application, I need to get a reference to the underlying NSView. Hence, I need to have gdk.Window.get_nsview wrapped. For this, I proposed a patch to pygtk to wrap gdk_quartz_window_get_nsview(), introducing a dependency on AppKit.h (since the function returns a NSView*). To compile the pygtk bindings with this new function, I had to specify -ObjC in CFLAGS.
I could have introduced the option conditionally in the pygtk configure.ac, but since any application using gdk-quartz.h function would have to do so, I thought that it had better be in the origin of the dependency, gtk.

So presumably you're manipulating the NSView with pyobjc. I'm a bit surprised that doesn't introduce memory issues, especially if one isn't careful to ensure that both pygtk and pyobjc are linked against the same AppKit.framework (rather than one against the 10.5 SDK, say, and the other against /System/Frameworks).

I think that's playing with very sharp knives, and I suggest that it should be a configure option for pygtk, which defaults to disabled. You can then easily enough add the objective-c option to CFLAGS when it's enabled.

You do know that PyGtk is supposed to be unnecessary for Gtk+-3, replaced by introspection-based modules. gdkquartz.h doesn't appear to be exported in Gdk3.0.gir, so just adding a CFlag to the pc file isn't going to get you anywhere -- though it would on the Gtk+-2 branch, and it's much less likely there that people are using introspection, so it would be safer.

I did not specify any gtk+ version when reporting this issue, and actually, I had more in mind the working-and-deployed Gtk+-2 version rather than the soon-to-come Gtk+-3, with the old-fashioned pygtk bindings rather than the new gir based approach. Cannot be on the bleeding edge all the time...