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

[Jesse van den Kieboom <jessevdk gnome org>]

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

On Jan 10, 2012, at 2:32 AM, Jesse van den Kieboom wrote:

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)?

Nope, /Volumes/RAID1/local/gtk-foo (several, to test different builds) and /Volumes/RAID1/Gnucash-Build/Gnucash-(2.4|svn)

If python was lower-casing paths it would be even more of a problem on case-sensitive file systems like ext3. Something else is going on. Are you sure you're not passing in lower-cased paths in a config argument or environment variable somewhere?

The issue is this:

>>> os.getcwd()

'/users/jesse/gtk/10.4/source/enchant'

I don't know why the current working directory when retrieved from python is lowercase on my system, but it is.

 

 

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.

They can be in any encoding depending on OS, but for what Gtk+ supports, they *are* in either UTF8 (Linux and OSX) or UTF16 (Windows -- but doesn't GLib transcode them to UTF8?)

Well, not exactly. glib will try to guess file path encodings for you. In the end, if you use glib/gio you can get the paths both in the native encoding (i.e. a byte string with no guarentees) or a utf-8 encoded string, with possible escape sequences. In any case it's better to rely on glib/gio than doing string comparisons.

 

But why not patch it to use the gio functions? (I guess that's a question for the bug report rather than here.)

Yeah, it would work for me, too (except that I don't seem to have the problem) -- but neither of us have funny characters in our pathnames. 

Sure, it would be the right way to go, but for now I'm just going to try to get everything to build again since that takes enough time already :)

Jesse

 

Regards,

John Ralls

_______________________________________________
Gtk-osx-users-list mailing list
Gtk-osx-users-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-osx-users-list