Hi Hisham,
On 11/1/2011 12:48 AM, Hisham wrote:
> Still, I can't run the samples. They fail with:
>
> Lgi-Message: Lua to GObject-Introspection binding v0.1
> lua: /Users/hisham/.luarocks/share/lua/5.1/lgi.lua:792: Failed to load
> typelib file '/System/Index/lib/girepository-1.0/Gtk-2.0.typelib' for
> namespace 'Gtk': Typelib version mismatch; expected 4, found 2
> stack traceback:
> [C]: in function 'assert'
> /Users/hisham/.luarocks/share/lua/5.1/lgi.lua:792: in function
> </Users/hisham/.luarocks/share/lua/5.1/lgi.lua:790>
> (tail call): ?
> ./gtkpad.lua:14: in main chunk
> [C]: ?
>
> (Nevermind the weird /System/Index/ and /Users/ paths, this is a
> Linux[1] system.)
>
> What version of GTK+ should I have to run this? I currently have
> 2.24.6 installed. Perhaps this version check for Gtk should be part of
> your dependency checking?
The problem here is that you have correctly rebuilt
gobject-introspection library from source, but your other packages
(namely Gtk) still have .typelib files built with older, unfortunately
incompatible version. You'll have to rebuild any package you'd like to
use with LGI with new gobject-introspection installed (this will
recompile .typelib using newer g-ir-scanner and g-ir-compiler G-O-I
tools). giosample worked, because G-O-I builds GLib, GObject and Gio
typelibs during its own build.
But then you'll probably meet another hurdle. I've developed and tested
LGI samples against GTK3, and there are some API incompatibilities
between GTK2 and GTK3. Principally, LGI can work also with GTK2, but
you'll likely have to update the samples :-( I'm not sure how to cope
with this situation, checking GTK3 as a prerequisite seems to be wrong
(it is possible to use LGI even without GTK at all).
> Another issue I noticed is that you build lgi.so and lgi.lua. To my
> almost-surprise this works [2] but personally I don't recommend the
> practice. The existence of two different files is not accounted for in
> "luarocks show", for example, which assumes that module files have
> unique names; this practice would be probably confusing for
> documentation as well. Packages such as LuaSocket use explicit 'core'
> modules, such as "socket.core" (socket/core.so).
Hmm, thanks for noticing. Now this seems like bad design decision. I'll
change it as suggested (but probably for 0.2).
BTW, what is the preferred luarocks mechanism for updating installed
package? Is user expected to do "luarocks remove $pkg && luarocks
install $pkg"?
> Just as an exercise to test the versatility of LuaRocks, I tried
writing a
> rockspec that builds your package without using waf. The results
> follow attached. Apparently, it builds and installs the modules just
> as well (at least I stall at the same errors when running the samples
> (note: the giostream.lua sample runs) ). The major downside is that
> pkg-config is not used, so external dependencies are not version
> checked and some of the incdir particulars may change from distro to
> distro. I tried to keep the tool general and avoid supporting every
> tool out there, but it may be a good idea to add explicit support for
> pkg-config in LuaRocks.
I originally tried to use native luarocks build, but met some problems:
1) external_dependencies = { GLIB = { library = "glib-2.0" } }
generated /usr/lib path, although my system (Fedora16, x86_64) has 64b
libraries in /usr/lib64. This broke later in
incdirs = { ... "$(GLIB_LIBDIR)/glib-2.0/include" }
because glibconfig.h exists only in /usr/lib64/glib-2.0/include, not
/usr/lib/glib-2.0/include
2) ffi.h file (from libffi package) is present only in
/usr/lib64/libffi-3.0.7/ffi.h - IOW, it is safely discoverable only by
pkg-config (because of version symbol in the directory name).
At this point, I gave up and decided to go with my existing ./waf build.
I think that luarocks would need native pkg-config support to make
this kind of build to work reliably.
> I'll wait for your feedback on the Gtk dependency issue before
> uploading the module to the package repository.
Ok, please wait a bit more, I'll try to find out how feasible is it to
port samples to Gtk2, because there wil be probably more users bitten by
this issue. I'll let you know then.
Thanks a lot for trying so hard to make it work!
Pavel
------------------------------------------------------------------------------
RSA® Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Luarocks-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/luarocks-developers
