GNOME Bugzilla – Bug 678883
gtkmm 3.4.0 fails to build quartz backend (in gtk/gtkmm/wrap_init.cc)
Last modified: 2012-07-22 05:48:25 UTC
Created attachment 217293 [details] console log (gtkmm 3.4.0, OS X 10.7.4) Gtkmm 3.4.0 (source package) fails to build the quartz backend on Mac OS X, apparently trying to include x11 header files (via plug.h) not present in a quartz-based build environment for GTK3. System: OS X 10.7.4, Xcode 4.3.2 Build environment: based on MacPorts, not jhbuild (gtk-osx) (mm-common is not available to test building from git) $ clang --version Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn) $ pkg-config --modversion --variable=targets gtk+-3.0 3.4.3 quartz Related earlier report: bug 662975 (AFAICT the changes for that bug had been committed to the gtkmm-3.4 branch)
Bug 662975 does not fix the problem completely. glibmm/tools/generate_wrap_init.pl regenerates wrap_init.cc only in maintainer mode: ./configure --enable-maintainer-mode; make gtkmm/gtk/src/filelist.am contains conditional inclusions of files, controlled by 3 automake variables, if HOST_WINDOWS_NATIVE if DISABLE_DEPRECATED_API if GDK_TARGET_X11 HOST_WINDOWS_NATIVE corresponds to the m4 macro _GTKMMPROC_WIN32_NO_WRAP in the .hg file. When generate_wrap_init.pl finds this m4 macro, it surrounds the corresponding code in wrap_init.cc by #ifndef G_OS_WIN32 / #endif. Similarly DISABLE_DEPRECATED_API corresponds to the m4 macro _IS_DEPRECATED and #ifndef GTKMM_DISABLE_DEPRECATED / #endif. GDK_TARGET_X11, on the other hand, excludes some .hg files from the list of files that generate_wrap_init.pl processes, but that's done when wrap_init.cc is generated, not when it's compiled.
Created attachment 217769 [details] [review] patch: generate_wrap_init.pl: Add _GMMPROC_WRAP_CONDITIONALLY. (glibmm) This patch adds the _GMMPROC_WRAP_CONDITIONALLY m4 macro, and code in generate_wrap_init.pl to handle it. The code it writes in wrap_init.cc can be controlled by any #if/#ifdef/#ifndef directive, not just by #ifndef G_OS_WIN32. It would of course be possible to add a macro specially for X11, e.g. _GMMPROC_X11_WRAP, but I prefer the more general _GMMPROC_WRAP_CONDITIONALLY. With that macro, almost any conditional compilation of parts of wrap_init.cc can be added without modifying generate_wrap_init.pl or any of the m4 files. Example: _GMMPROC_WRAP_CONDITIONALLY(`if defined(GDK_WINDOWING_X11) || defined(GDK_WINDOWING_QUARTZ)') (generate_wrap_init.pl requires the whole macro call to be on one line, but Bugzilla doesn't like long lines.)
Created attachment 217770 [details] [review] patch: Fix wrap_init() for Quartz (MacOS). (gtkmm) This patch depends on the glibmm patch in the previous comment.
There's a flaw in my patches in comments 2 and 3. There must be a way to tell generate_wrap_init.pl that it shall include gdk/gdk.h before it inserts any #ifdef GDK_WINDOWING_X11. (gdk/gdk.h includes gdk/gdkconfig.h, which defines GDK_WINDOWING_X11 or any other GDK_WINDOWING_* constant.) I'll attach better patches, when I have any to attach.
Created attachment 217852 [details] [review] patch: generate_wrap_init.pl: Add _GMMPROC_WRAP_CONDITIONALLY. (glibmm) Replaces the patch in comment 2. Adds both _INCLUDE_IN_WRAP_INIT and _GMMPROC_WRAP_CONDITIONALLY.
Created attachment 217853 [details] [review] patch: Fix wrap_init() for Quartz (MacOS). (gtkmm) Replaces the patch in comment 3.
It looks good to me and we'll soon know if it causes any problems. Feel free to push it. Thanks.
I've pushed the patches. It _will_ cause problems for anyone who fetches the latest version of gtkmm without also fetching the latest version of glibmm.
JFTR: gtkmm 3.5.6 (source package), with glib 2.33.4 and glibmm 2.33.3 installed, builds the quartz backend out-of-the-box [1] on OS X 10.7.4 (Xcode 4.3.2). <off-topic> My goal is to test Inkscape trunk with GTK3 (experimental [2]) on OS X using the Quartz backend of GTK3. Test builds with the X11 backend of latest stable GTK3 are ok (no major issues). Unfortunately, Inkscape built with the Quartz backend of GTK3 is unable to load any theme engines (neither Adwaita, nor Unico). I haven't yet been able to narrow this down to either an issue with my custom build setup, or to a problem with the Quartz backend of gtkmm-3 (since I'm not coding C/C++ myself, filing upstream reports for build dependencies is tricky ;-) ). </off-topic> [1] build setup: MacPorts 2.1.1 (installed into a separate prefix for each backend of GTK+) + local portfile repositories for ports not yet available in the main repo [2] see <https://blueprints.launchpad.net/inkscape/+spec/gtk3-migration>
<off-topic cont.> > (…) built with the Quartz backend of GTK3 is unable to load > any theme engines (…) This was apparently due to a mistake on my part (GTK3 configured with '--enable-quartz-relocation' even though current test builds are not packaged as osx app bundle (see comments in bug #658772)). After rebuilding GTK3 without that configure option, theme engines are loaded just fine (both by gtkmm-demo and inkscape). </off-topic> Many thx for fixing building the quartz backend!