Re: [gtk-osx-users] gobject-introspection g-ir-scanner not working (stable moduleset)

[Jesse van den Kieboom <jessevdk gnome org>]

2012/1/9 John Ralls <jralls ceridwen us>

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?

I think it has something to do with python returning lower case paths, while some code path in C is constructing paths with actual casing (in particular /Users). Maybe you are using a different prefix than me (for example /opt)?

 

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.

Actually, paths can be in any encoding and comparing them by string comparison is never a good idea. These days we have facilities in gio that handle these kinds of things. By using GFile and g_file_equal this problem can be handled more generally. Unfortunately, things like g-i are not written necessarily with portability in mind. Anyway, even if it might not be entirely correct in all cases, for now using g_ascii_strcasecmp seems the easiest one line fix to get introspection scanning to work. And since this is only needed at compile time (not when running an application) it's ok for me.

Jesse

 

Regards,

John Ralls