On Jan 9, 2012, at 4:47 AM, Jesse van den Kieboom wrote: 2011/11/8 John Ralls <jralls ceridwen us>
On Nov 6, 2011, at 11:18 AM, Jesse van den Kieboom wrote:
> Hi all,
>
> I'm trying to compile a gtk+3 environment using the current stable moduleset (gnome 3.2 basicly). I am encountering a problem with g-ir-scanner which I'm not sure how to solve. When compiling gtk+3, g-ir-scanner will generate an (almost) empty Gtk-3.0.gir file. It doesn't give any indication of problems, warnings or errors. Has someone encountered this before?
Jesse,
I did a test just now it it looks OK to me:
ls -l Gtk-3.0.*
-rw-r--r-- 1 john staff 4913117 Nov 7 15:27 Gtk-3.0.gir
-rw-r--r-- 1 john staff 551004 Nov 7 15:27 Gtk-3.0.typelib
You need to build meta-gtk-osx-gtk3 instead of meta-gtk-osx-core, and I think that it's safest to do it into a clean prefix just to make sure that there aren't any conflicts with the gtk2 stuff.
I actually found the problem, which has to do with the fact that file paths on HFS+ are case insensitive by default (and on my system) and that the gi-scanner assumes case sensitivity (they compare paths with strcmp, which in any case is not verry correct for file paths). I filed a bug here: https://bugzilla.gnome.org/show_bug.cgi?id=667405 and have a local patch to change the strcmp to strcasecmp. For those interested, this is the patch:
--- a/giscanner/sourcescanner.c 2012-01-05 17:55:08.000000000 +0100 +++ b/giscanner/sourcescanner.c 2011-08-25 21:49:38.000000000 +0200
@@ -246,7 +246,7 @@ g_assert (scanner->current_filename); for (l = scanner->filenames; l != NULL; l = l->next) { - if (strcmp (l->data, scanner->current_filename) == 0)
+ if (g_ascii_strcasecmp (l->data, scanner->current_filename) == 0) { found_filename = TRUE;
break;
Interesting.
But I also use the default case-preserving-but-insensitive HFS+ settings, and I don't see the problem. Since HFS+ is case-preserving, why would the case of a pathname change while g-ir-scanner is doing its thing?
Also note that paths these days can be Unicode -- regardless of OS -- so both strcmp() and g_ascii_strcasecmp() are wrong. Unfortunately GLib doesn't provide a unicode comparison facility, so you'd need to call g_utf8_normalize() and g_utf8_casefold() on both strings, then g_strcmp0 the results.
Regards, John Ralls
|
