GNOME Bugzilla – Bug 628936
gtk build fails because of objective-c elements
Last modified: 2012-03-02 19:40:23 UTC
Created attachment 169644 [details] [review] Rearrange Makefile.am to hide objective-c from g-ir-scanner G-ir-scanner doesn't like objective-c, but gtk/Makefile.am passes a gcc option (-xobjective-c) and files (gtkquartz.c and gtksearchenginequartz.c)containing objective-c to it. Attached patch rearranges Makefile.am slightly to hide the option and files from g-ir-scanner.
IMHO the correct fix is to replace $(gtk_all_c_sources) with $(gtk_c_sources) in the introspection_files variable, instead.
Created attachment 169689 [details] [review] Lower-impact, more correct rearrangement Using gtk_c_sources would actually defeat part of the change, which is to hide gtksearchenginequartz.c and gtkquartz.c from the scanner. gtk_c_sources includes those when building for quartz. This new patch doesn't move gtk_clipboard_dnd_c_sources out of gtk_basic_c_sources. Instead, it moves gtkquartz.c from gtk_clipboard_dnd_c_sources to gtk_use_quartz_c_sources so that it isn't added to gtk_all_c_sources. If it's indeed unnecessary to submit all of the "use_platform" sources (except for gtksearchenginequartz.c and gtkquartz.c) to the scanner, then one should define a new variable gtk_introspection_c_sources and take the "stub" sources out of gtk_use_quartz_c_sources. When building quartz gtk_c_sources would include gtk_quartz_c_sources and gtk_introspection_c_sources would not. That would require testing on all three platforms.
Well, the change in comment 1 is enough to fix this for non-osx (since all_c_sources includes the osx sources also on non-osx). Fixing it for osx itself does indeed need more changes.
No, look again: gtk_all_c_sources does *not* include quartz sources, no matter what platform it's building for (even quartz). Maybe it should, but it doesn't. So I don't think that there's a problem to fix on non-OSX builds.
(In reply to comment #2) > Created an attachment (id=169689) [details] [review] > Lower-impact, more correct rearrangement > > Using gtk_c_sources would actually defeat part of the change, which is to hide > gtksearchenginequartz.c and gtkquartz.c from the scanner. gtk_c_sources > includes those when building for quartz. > > This new patch doesn't move gtk_clipboard_dnd_c_sources out of > gtk_basic_c_sources. Instead, it moves gtkquartz.c from > gtk_clipboard_dnd_c_sources to gtk_use_quartz_c_sources so that it isn't added > to gtk_all_c_sources. Aren't gtkclipboard-quartz.c and gtkdnd-quartz.c still passed to the IR scanner now? Both contain objective-C, so the scanner will still break?
Yes, they are, but the scanner doesn't break, it just whines about the "@" which introduces strings: gtk/gtkclipboard-quartz.c:80: unexpected character `@' See bug 626995.
So the scanner breaks for gtkquartz.c and gtksearchenginequartz.c, and it does not break for gtkclipboard-quartz.c and gtkdnd-quartz.c? I don't really get that, because I don't see gtkclipboard-quartz.c and gtkdnd-quartz.c use "less" Objective-C than gtksearchenginequartz.c ...
Created attachment 174965 [details] [review] Reduced patch: Only changes compiler flags You're right, and I don't at this point remember why I made the distinction. If you prefer, this patch only changes the compiler flag.
Created attachment 196281 [details] [review] Minimal patch updated to apply to master of 11Sep2011
(In reply to comment #9) > Created an attachment (id=196281) [details] [review] > Minimal patch updated to apply to master of 11Sep2011 One possible disadvantage of this approach is that all files are now compiled with -xobjective-c turned on. If we would introduce objective-C code in generic GTK+ C sources by accident, then the compiler wouldn't notice for us. (The Linux people would though :). I don't have problems with having -xobjective-c turned on for the entire build and would be fine with this going in. Matthias: could you comment here as well, since it does in theory touch non-quartz parts of Makefile.am ?
in Clutter I enabled -xobjective-c when building on OS X — though that was a necessity since Clutter uses a non-recursive layout — and never had any issue.
(In reply to comment #10) > One possible disadvantage of this approach is that all files are now compiled > with -xobjective-c turned on. If we would introduce objective-C code in > generic GTK+ C sources by accident, then the compiler wouldn't notice for us. > (The Linux people would though :). That's true now, because ${gtk_clipboard_dnd_c_sources_CFLAGS} gets added to AM_CPPFLAGS. (gtk_use_quartz_CFLAGS is a no-op.) AFAIK, there are only per-target CFLAGS in Automake, not per-source. I think that the only way to have -xobjective-c turned on for only those files which need it (and BTW gtkselection.c is one of them) would be to break them out into a separate convenience library and then link that back in to libgtk. Do you guys really want to go that route?
Comment on attachment 196281 [details] [review] Minimal patch updated to apply to master of 11Sep2011 Let's commit it, seems ebassi has positive experiences with this.
Comment on attachment 196281 [details] [review] Minimal patch updated to apply to master of 11Sep2011 Pushed onto gtk-2-24, gtk-3-2, and master.
*** Bug 642085 has been marked as a duplicate of this bug. ***